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The information contained in this manual 
is intended for programmers engaged in 
Maintenance of BDAM routines. 


This publication is divided into three 
Main parts. The first part describes the 
organization and function of the basic 
direct access method and its relationship 
to other portions of IBM System/360 Operat- 
ing System. The second part describes the 
main components of the basic direct access 
method and their interaction. Part three 
contains reference material that is not 
necessary to an understanding of the logic 
of the access method but may be useful in 
understanding a storage dump or in other- 
wise analyzing the listings for this access 
method. 


To provide the prerequisite knowledge 
for understanding the contents of this 
publication, the following publications are 
recommended: 


For information regarding the primary 
control program, see: 


IBM System/360 Operating System: Intro- 
duction to Control Program Logic, Pro- 
gram Logic Manual, Form Y28-6605 


For information regarding the MVT 
figuration of the control program, see: 


con- 


IBM System/360 Operating System: Control 
Program Logic Summary, Form Y28-6658 


The following publications are listed as 
suggested reading: 


PREFACE 


IBM _ System/360 Operating System: Super- 


visor and Data Management Services, Form 
C28-6646 


IBM System/360 Operating System:  Super- 


visor and Data Management Macro- 
Instructions, Form C28-6647 


IBM System/360: Component Description, 
2841 Storage Control Unit 
2302 Disk Storage, Models 3 and 4 
2311 Disk Storage Drive 


2321 Data Celli Drive, Model 1 


7320 Drum Storage, Form A26-5988 


This publication also makes references 
to routines that are described in one of 
the following publications: 


IBM System/360 Operatin System: 


Input/Output Support  (OPEN/CLOSE/EOV), 
Program Logic Manual, Form Y28-6609 


IBM System/ 360 Operating System: 


Sequential Access Methods, Program Logic 
Manual, Form Y28-6604 


IBM System/360 Operating System: Direct 


Access Device Space Management, Program 
Logic Manual, Form Y28-6607 


IBM System/360 Operating System: MVT 


Supervisor, Program Logic Manual, Form 
Y¥28-6659 
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The basic direct access method (BDAM) 
consists of routines used in retrieving 
data from, and storing data onto, direct 
access devices. In this capacity, the BDAM 
routines are a part of the IBM System/360 
Operating System control program, and they 
operate in conjunction with the 
input/output supervisor (I/O supervisor). 
The BDAM routines link a processing program 
to system supervisor routines in order to 
satisfy input/output requests for data in 
direct-organization data sets. 


The BDAM routines are grouped into 
modules and placed in the supervisor call 
(Svc) library at system generation time. 
This library is part of the system resi- 
dence library that resides on direct-access 
storage. When the BDAM routines are to be 
used by a processing program, the necessary 
modules are brought from the system resi- 
dence volume and ioaded into main storage. 
The loaded BDAM modules are linked by 
module storage addresses. Each address is 
placed in one of the following: 


e The data control block (DCB) for the 
data set. 


¢ Another previously loaded BDAM module. 


e The BDAM appendage list that is in 
protected main storage. 


Essentially, BDAM may be divided into 
three general sections: an opening section, 
a processing section, anda closing sec- 
tion. 


The opening section initializes the 
access method by determining storage 
requirements, by determining and loading 
the required modules from system residence, 
and by building control blocks and control 
lists for further program usage. 


The processing section does the follow- 
ing: 


® Converts address to a form required by 
a channel program. 


e Constructs, and initiates execution of, 
a channel program for fulfilling an 
input or an output request macro 
instruction. 


e Maintains exclusive control of informa- 
tion in a block as long as requested. 


INTRODUCTION 


e Assigns buffers for input/output opera- 
tions. 

e Indicates errors related to 

input/output operations. 


The closing section performs the func- 
tions that are necessary to terminate nor- 
mal processing of a BDAM data set. 


Throughout this publication, references 
are made to control blocks or to fields of 
a control block. Appendix A contains a 
description of the major control blocks 
used by BDAM. 


RELATIONSHIP OF THE BASIC DIRECT ACCESS 
METHOD TO THE OPERATING SYSTEM 


When a data set to be processed using 
BDAM is opened, the open routine of data 
management (discussed in the publication 
IBM System/360 Operatin System: 
Input/Output Support (OPEN/CLOSE/EOV), Pro- 
gram Logic Manual) gives control to one of 
the BDAM modules that initialize the access 
method routines for the type of processing 
indicated in the DCB. 


The basic direct access method also has 
interfaces with the processing program and 
with the supervisor. When either a READ or 
a WRITE macro instruction in the processing 
program is encountered, the BDAM routines 
begin satisfying the request. The actual 
execution of a request requires a channel 
program that has been constructed by one or 
more BDAM routines. 


When an input/output operation termi- 
nates, the processing program is interrupt- 
ed. The I/O supervisor then obtains’ the 
address of a BDAM appendage module and 
gives control to that module to schedule 
the remaining processing required for the 
request. When all processing for the 
request has been completed, the supervisor 
returns control to the processing program. 


Note: The BDAM start I/O appendage module 
is always given control just before the 
execution of a request begins. If dynamic 
buffering is specified, control is given to 
the BDAM dynamic buffering module. 


When a data set is closed, the data 
management close routine gives control to 
the BDAM close executor module, which then 
completes the BDAM functions. 
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STRUCTURE OF THE BASIC DIRECT ACCESS METHOD 


The modules of BDAM can be grouped into 
several categories that are related to the 
purpose or function of the module. These 
categories are: 


Opening a DCB. 

Controlling the processing. 
Converting addresses. 

Generating channel programs. 

I/O supervisor appendages. 
Maintaining exclusive control. 
Providing dynamic buffer allocation. 
Checking for request completion. 
Closing the DCB. 


OPENING A DCB 


To open a DCB for a BDAM application, 
two, and sometimes three, modules are 
required. These modules are the BDAM open 
executor modules, and they are used when a 
DCB for a direct organization data set is 


opened. The need for three modules depends 
on the options selected in the DCB macro 
instruction. The collective functions of 


these modules are to determine the need for 


other modules and to establish control 
blocks. 
CONTROLLING THE PROCESSING 

The module that controls the processing 


of BDAM is called the foundation 
This module is given control when 
a READ or a WRITE macro instruction 


functions 
module. 
either 


that uses BDAM is encountered in a process- . 


ing program. It is used to complete the 
preparations necessary before a request can 
be executed and completed. The foundation 
module checks the validity of each request 
and contains the linkage to some of the 
other required modules. 


An additional function of the foundation 
module is to complete the processing of a 
request after an input/output operation has 
terminated. (Refer to the section 
“Asynchronous Interrupt Component” for 
further information about this function.) 


CONVERTING ADDRESSES 


Five modules are used for address_  con- 


version. Two of these modules are used to 
convert a block address that has been 
specified as a relative block address into 


an actual device address. The choice of 
which one is to be used depends on whether 
or not track overflow is specified in the 
DCB macro instruction. Another of the five 
modules converts addresses from a relative 
track specification to an actual device 
address. The other two conversion modules 
are used only if the programmer specifies 
feedback with relative block addressing. 
Again, the choice depends on the _ track 
overflow specification. 


GENERATING CHANNEL PROGRAMS 


Several channel program generation 
modules are available as part of BDAM. At 
least one of these modules is used for 
every BDAM request that is normally com- 
pleted. These channel programs either 
search auxiliary storage volumes for infor- 
mation to be brought into main storage or 
search auxiliary storage volumes for space 
on which to place information that is 
transferred from main storage. The selec- 
tion of the required module is based on 
whether an existing block is being read or 
updated or a new block is being added to a 
data set. One additional channel program 
is used if it is required to verify data 
that is written on secondary storage 
volumes. 


Reading or Updating Blocks 


There are three modules used to generate 
channel programs for block reading or 
updating purposes. The choice of modules 
depends both on which part (either the key 
field or the block identification portion 
of the count field) of the data block is 
used aS a search argument in the data 
retrieving function of the channel program 
and on whether an option has been selected 
to permit extending the search of a data 
set beyond a given track. 


Adding New Blocks 


There are three modules available to 
generate channel programs for adding new 
blocks to an existing data set. These 
modules are referred to as format modules 
Since the use of a particular module 
depends on the block format in the data set 
being processed. The modules used for 
fixed-length (pre-format) blocks are dif- 
ferent from those used for variable-length 
(self-format) blocks. Blocks whose lengths 
are undefined also are called self-format 
blocks. The number of modules required 


« 
e 


when adding new blocks depends on whether 
the extended search option has been 
specified. 


Verifying Written Data 


ff written data is to be verified, there 
is one module used to generate the required 
channel command words. This channel pro- 
gram contains channel command words that 
are appended to the appropriate "write- 
type" channel program. The module is 
required if the write-validity-check option 
has been specified in the DCB. 


I/O SUPERVISOR APPENDAGES 


There are three BDAM modules to which 
I/o supervisor may pass control, depending 
on the stage of execution of a request. 

The first is the start I/0 appendage 
module. If the dynamic buffering option 
has been specified, the appendage module 
permits the allocation or release of buffer 
areas. I/O supervisor accordingly passes 
control to this module before beginning the 
‘channel program for such requests. 


The second appendage module is the chan- 
nel end appendage module. This module 
schedules further processing on a request 
after a channel program has terminated. 


The third I/O supervisor appendage 
module is the end of extent appendage 
module. This module is loaded if the 
extended search option has been’ specified. 


It receives control if the channel program 
in control is required to switch from one 
extent to another while reading a block, 
writing an updated block, or adding a new 
block. 


MAINTAINING EXCLUSIVE CONTROL 


control module provides 
block 


The exclusive 
protection for the data portion of a 


requested under exclusive control py ensur- 
ing that supsequent duplicate requests for 
the plock are not posted as complete before 
the initial request for the block has 
released control. A read-exclusive list is 
established to nelp ascertain if a given 
request is a duplicate request. 


In a multi-task environment, this module 
places blocks on, and removes blocks’ from, 
an inter-task queue to provide block pro- 
tection during updating. In this cavacity, 
the module serves requests for adding new 
blocks as well as requests using the exclu- 
Sive control option. 


PROVIDING DYNAMIC BUFFER ALLOCATION 


The dynamic 
assigns, and 
input/output 


buffer module obtains, 
releases buffer areas for 
requests that use the dynamic 
buffer option. A buffer control block and 
a buffer queue are established to handle 
the buffer requests. 


CHECKING FOR REQU:ST COMPLETION 


The check module contains provisions 
both for determining if (and waiting, if 
necessary, until) a request has been posted 


as complete and for giving control to a 
user's error routine if errors nave been 
indicated during the input or output 
operation. 


CLOSING THE DCB 


Tne BDAM close executor module is the 
only module in this category. This module 
is required to release, to the system, the 
main storage obtained by BDAM. 


The second function of this module is to 


restore the fields of tne DCB tnat have 
been changed by BDAM routines. 
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PROGRAM COMPONENT DESCRIPTION 


The main components of BDAM are de- 
scribed in the following paragraphs. The 
modules required within each component, the 
conditions under which the modules are 
used, and the inter-module relationships, 
are discussed. Where appropriate, figures 
are used to illustrate the text descrip- 
tion. Figure 16, following Appendix Cc, is 
a composite of Figures 1, 3, 4, 7, and 8 
that are referred to in this section of the 
puplication. It may be useful in gaining 
an overall general concept of BDAM ani its 
relation to a processing program and to the 
operating system. 


THE BDAM OPEN EXECUTOR PROGRAM 
(MODULES IGG0193A, IGG0193C, AND IGG0193£) 


The BDAM open executor program consists 
of up to three modules that are given 
control during the opening of a data con- 


trol block specifying BDAM. The routines 
in these modules obtain storage for, set 
up, and initialize control blocks used by 


BDAM routines, and load the required BDAM 
processing modules into main storage. 


When the OPEN macro instruction is 
encountered in a processing program that 
specifies BDAM, the expansion of the macro 
instruction causes control to be passed to 
the open routine of data management. (See 
Figure 1.) This routine uses the BDAM open 
executor modules as subroutines. It gives 
control to module IGG0193A (referred to as 
phase 1 of the BDAM open executor program) 
to initiate the BDAM processing. Parame 
ters specified in the DCB to which the OPEN 
macro instruction refers and in the data 
set control block (DSCB) for this data set 
enable phase 1 to determine the protected 
Main storage requirements for the data 
extents to be added to the base of a data 
extent block (DEB). Phase 1 then obtains 
main storage for an I/O supervisor appen- 
dage list, a read-exclusive list (a list of 
the addresses of blocks still under exclu- 
Sive control), and the DEB, and places 
necessary control information in the fields 
of the DEB. A user label track, if allo- 
cated, is not included in the extents 
reflected in the DEB. As each current DEB 
is being constructed, it is attached to the 
appropriate task control block for future 
reference. 


In allocating storage for the DEB, 
phase 1 also provides space for the identi- 
fication of BDAM modules that are required 
as a result of specifications given in the 


UDCBMACRF field, the DCBOPTCD field, and the 
DCSRECFM field of the DCB. 


After the preceding functions have been 
completed, pnase 1 checks the where-to-go 
table, which is created by the data manage- 
ment open routine, to determine whether it 
includes other DCBs that require the use of 
tnis phase. If there are no more current 
requirements for the use of phase 1, con- 
trol is given to module IGG0193C (referred 
to as phase 2 of the BDAM executor 
program). 


Phase 2 loads into main storage the BDAM 
modules used for the particular applica- 
tion. The foundation module is loaded 
first. Phase 2 olaces in the foundation 
module the addresses of certain optional 
BDAM modules that have been selected. The 
addresses of the remaining BDAM modules are 
placed either in the DCB, in the I/0 
supervisor appendage list, or in other 
designated modules. Table 1 shows where 
the module addresses are placed. Each time 
BDAM is used, the addresses of the selected 
modules are placed in the same -designated 
positions in the control blocks, modules, 
or lists. 


The major activity of phase 2 is the 
selecting of required modules. There is a 
routine within the module for each of the 
following activities: 


e Selecting and loading the proper 
addressing module. 
e Determining and loading the proper 


channel program generating module(s). 


e Determining and loading the optional 
module(s) required. 


e Determining and loading the 
appendage modules. 


required 


If main storage already contains some 
BDAM modules from a previous data _ set 
opening, phase 2 obtains their main storage 
addresses from the supervisor, and these 
modules are not reloaded. There are two 
Situations to consider: 


1. If BDAM modules have been included in 
the link pack area, then they are 
accessible to all jobs requesting them 
(since the BDAM modules are reenter- 
able). Since some of the BDAM modules 
branch to each other via addresses 
placed within them by an Open execu- 
tor, these modules must be included as 


cw 


z 
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a unit in the link pack area. See the 


publication IBM System/360 Operating 
System: Storage Estimates. 


2. If a given task loads a BDAM module 
into a region assigned to that task, 
only that task or a subtask attached 
by that task has access to the module. 
If another main task requires the 
same module, it must load the module 
into its own region. 


The MVI Supervisor Program Logic Manual 
contains more detailed information concern- 
ing these situations. 


As modules are loaded into main storage, 
their corresponding identifications are 
placed in the DEB. (After processing has 
been completed on a data set, the close 
routine uses. this information for releasing 
storage areas.) Soace for tne module iden- 
tifications was allotted by phase 1 of the 
BDAM open executors. 


Phase 2 also initializes the read- 
exclusive list and some of the fields of 
the DCB. 
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Figure 1. Relationship Among Processing Program, Data Management Open Routine, and BDAM 
at Open Time 


Table 1. BDAM Module Addresses as Stored by Phase 2 of BDAM Open Executor Program 


CS a a ee ee ee 1 
| | Module, Control Block, or List | 
| Module Name | in Which Address Is Placed | 
}--~--------~-------------~----------------- }-------------~------------------------------ { 
| Foundation | DCB j 
| Relative Track | Foundation Module | 
| Write-Verify | Foundation Module | 
| Relative Block Feedback | DCB | 
| Key | Foundation Module | 
| Key Extended Search | Key Module | 
| ID | Foundation Module | 
| Self-Format { DCB | 
| Self-Format Extended Search | Self-Format Module | 
| Pre- Format | DCB | 
| Pre-Format Extended Search | Pre-Format Module | 
| Start I/0 | Appendage List? j 
| End of Extent | Appendage List | 
| Channel End | Appendage List | 
| Check | DCB | 
| Dynamic Buffer | DCB | 
| Exclusive Control? | DCB | 
}------------------------------------------ }~------------------------------------------- { 
| 4The address of the Appendage List is in the DEB. | 
| 27The address of the read-exclusive list is also in the DCB. | 
lee aa a a a a a ae a J 
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The remaining function of phase 2 of the 
open executor program is the branching to a 
supervisor routine to build the interrupt 
request block (IRB). 


Before giving control to the next 
routine, phase 2 determines if any more 
DCBs associated with the current OPEN macro 
instructions require the use of this 
module. If so, this module is reentered 
and does the required processing. Other- 
wise, two situations are considered: 


1. If neither the dynamic buffer option 
nor the relative block addressing 
option has been specified in the DCB 
macro instruction, the data set is 
considered to be opened as far as BDAM 
is concerned, and control is returned 
either to an open executor routine for 
another data set or to the open rou- 
tine of input/output support?. 


2. If the DCB macro instruction specifies 
either the relative block addressing 
option or the dynamic buffering 
Option, or specifies both options, 
phase 2 gives control to module 
IGG0193E (phase 3 of the BDAM open 
executor program). 


If it is indicated in the DCBOPTCD field 
of the data control block that BDAM should 
handle all buffer management for a given 
data set, module IGG0193E uses the buffer 
information in the DCB macro instruction to 
obtain the required amount of main storage 
for the buffers anda control block (the 
buffer control block) to contain buffer 
information. The buffer area in storage is 
then divided into the requested number of 
buffers, and the buffers are chained 
together so that the dynamic buffer module 
May Satisfy the buffer requirements for 
individual read or write requests. (Refer 
to "Dynamic Buffering.") 


To gain access to a data _ set block 
located on a direct-access device, the 
block's actual location on the device must 
be known. If a programmer has’ specified 
that the blocks in a data set are to be 
referred to by relative block number (i.e., 
relative block addressing), then these num- 
bers must be converted to actual block 
locations (i.e., device addresses). For 
use in this conversion, phase 3 of the BDAM 
open executor program constructs a set of 
fields (known as relative extent fields) in 
the DEB. These fields of the DEB are 


4The next routine is determined from the 
where-to-go table. (Refer to the publica- 


tion IBM System/360 Operating System: 
Input/Output Support (OPEN/CLOSE/EOV), Pro- 


ram Logic Manual.) 


described in Appendix A. There is a one- 


to-one correspondence between the actual 
data set extents in the DEB and the 
relative data set extents. (Refer to 


"Relative Block Conversion.") 


If relative block addressing and track 
overflow are indicated in the DCBOPTCD and 
DCBRECFM fields of the DCB respectively, 
phase 3 constructs a modified relative 
extent portion of the DEB. In addition, 
phase 3 inserts two other fields between 
the last actual extent and the first rela- 
tive extent in the DEB. These fields are 
referred to as the overflow section of the 
DEB and are related to the concept of a 
period as discussed in the following para- 
graphs. 


Periods of an Extent 


When the basic sequential access method 
(BSAM) places blocks on a direct-access 
device, it is possible that a block may 
start on one track and finish on a_ follow- 
ing track within the same extent. Such a 
block is called an overflow block, and for 
this to occur, at least one byte of the 
data portion of a block must fit on a track 
in order for the block to overflow onto the 


next track. For purposes of calculation, 
the track on which a block begins is 
considered to contain the block. When a 


track is reached in which block length and 
track conditions do not permit at least one 
byte of the data portion of a new block to 
be written, the end of a period has been 
reached. ~- 


Thus, a period constitutes that group of 
tracks containing a group of blocks’ such 
that the first track does not begin with an 
overflow block from another track and the 
last track does not contain a block that 
overflows to another track. Example 1 
illustrates the concept of a period. 


In this example, assume the 


Example 1: 
following: 


e A given data set is on a device that 
permits 3625 bytes per track to be 
allocated to data blocks, excluding a 
track capacity record (RO). 


e The block length for the data set is 
844 bytes, divided as follows: 


14 bytes 

area 
100 bytes for the block key portion 
730 bytes for the block data portion 


for address marker plus count 
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e There are no inter-record gaps on the 
tracks. (This assumption is to simpli- 
fy the calculations in the example.) 


e Part of the given data set occupies an 
extent consisting of contiguous tracks 
beginning with track 47 on this device. 


From the second assumption, it is deter- 
mined that at least the first 115 bytes of 
a block must fit on a track in order for 
track overflow to occur. Figure 2 illus- 
trates the manner in which the data blocks 
would appear on the tracks of the extent. 


The identifications Bl, B2, ..., B32 
represent the first 32 blocks placed in 


this extent. The numbers above the block 
identifications represent the number of 
bytes of the block appearing on a track. 


Arrows at the end of a track and at the 
beginning of a track indicate where track 
overflow occurs. 


As shown in Figure 2, track overflow 
occurs from track 47 to track 48 (via block 
B5), from track 48 to track 49 (via block 
B9), and so on till the end of track 53. 
Since track: overflow (in this example) 
requires at least the first 115 bytes of a 
block to appear on ae track and only 55 
bytes remain on track 53 after block B30 
has been placed there, track overflow can- 
not occur using block B31. Therefore, 
tracks 47-53 constitute a period, and a new 
period begins with block B31 on track 54. 
For purposes of calculating relative block 
addresses (see Examples 2 and 3 in the 
section "Relative Block Conversion"), the 
number of blocks on each track is given in 
Figure 2 as the ‘Track Block Count‘. 


Based on block characteristics (key 


teristics, the third phase of the BDAM open 
program\computes the size of the period for 
the data set. Phase 3 then computes both 
the number of blocks in a period and the 
number of tracks in a period and places the 
computed values in the two fields of the 
overflow section of the DEB. These fields 
are each one word in length, and they occur 
only once for a given data set. The values 
placed in these fields are constant for a 
given data set. 


actual extents 
a data set is performed by 
space management routines (refer to the 


publication IBM System/360 Operating Sys- 


tem: Direct Access Device Space Management, 
Program Logic Manual), and since the period 


is a concept used by BDAM, the boundaries 
of extents and periods may not always 
coincide. However, the end of an extent 
terminates the last period in the extent. 
In this case, the last period may be 
complete or it may be only partially com- 
plete. In either case, the start of a new 
extent coincides with the start of a new 
period. 


Since the allocation of 
to members of 


Before returning control to the next 
routine, phase 3 determines if any more 
DCBs require the use of this module. If 
so, this module is réentered and does the 
required processing. If not, the data _ set 
is considered to be opened as-:far as BDAM 
is concerned, and control is returned eith- 
er to an open executor routine for another 
data set or to the open routine of 
input/output support.+ 


4The next routine is determined from the 
where-to-go table. (Refer to the publica- 
tion IBM System/360 Operating System: 


Input/Output Support (OPEN/CLOSE/EOV), Pro- 


length and data length) and device charac- qram Logic Manual.) 
: 844 844 844 844 249 Track Block Count 
Track 47 RO BI B2 B3 B4 B5 ~ = 5 Blocks 
595 844 844 844 498 ' 
Track 48 RO B5 Bé B7 B8 B9__-» = 4 Blocks 
346 844 844 . 844 747 
Track 49 RO te'po | B10 | B11 | B12 | B13 + 4 Blocks 
97 152 
B13 844 844 844 844 B18, 
Track 50 | RO E> B14 | B15 | B16 | BI7 i A Blocks 
692 844 844 401, 
Track 51 | RO al B18 | B19 | B20 | B21 | _B22—»! — 5 Blocks 
443 844 844 844 . 650 
Track 52 | RO [> B22 | B23 | B24 | B25 | B26 > 4 Blocks 
194 55 
B26 844 844 844 844 ¥ . 
Track 53 | RO Le | B27 B28 | B29 | B30 [} 4 Blocks 
844 844 Fe 
Track 54 RO B31 B32 ! 4 Blocks 
Fiaqure 2. Illustration of Track Overflow 
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THE BDAM FOUNDATION MODULE 
(MODULE IGG019KA) 


READ or a WRITE macro 
processing program is 
encountered, the BDAM foundation module 
receives control. (See Figure 3.) This 
module, IGGO19KA, is the basic module of 
BDAM. As such, it is required in all 
processing that requires the basic direct 
access method. This module provides’ the 
initialization, housekeeping, and control- 
ling functions for the BDAM processing 
routines. The foundation module consists 
of three main functional components: 


When either a 
instruction in the 


e The base component. 
e The asynchronous interrupt component. 
e The error component. 


BASE COMPONENT 


routine is the first main 
component of the foundation module. Ail 
requests made through either a READ or a 
WRITE macro instruction enter BDAM in the 
base routine. (See Chart 01.) The base 
routine has two primary functions: 


The base 


® Establishing the validity of options 
that have been specified in the request 
macro instruction for the application. 


e Combining the options specified in the 
type field of the READ or the WRITE 
macro instruction with the options 
specified in the DCBOPTCD field of the 
DCB. The result of the combination is 
placed in the data event control block 
(DECB) and later transferred to the 
input/output block (IOB) for future 
reference by the BDAM routines. 


The base routine then tests the type 
field of the DECB that results from the 
expansion of either the READ or the WRITE 
macro instruction, to determine the form of 
the channel program to be constructed. 
This routine then determines the main stor- 
age requirements for the IOB to be used by 
the request. (The I0OB used by a request 
for the BDAM program is described in Appen- 
dix A.) The base routine then either (a) 
obtains an available IOB of the necessary 
Size from an existing pool of IOBs or, (b), 
obtains an amount of main storage, through 
the use of the GETMAIN macro instruction, 
in which to construct a new I0B for the 
request and buiids the IOB. 


routine next determines the 
type of block addressing that has been 
specified for the data _ set. If actual 
addressing has not been specified, control 


The base 


is given to one of the BDAM modules that 
are used to convert the address form used 
to an actual address. (The main storage 
address of the required address conversion 
module was placed in the foundation module 
by the BDAM open executor program when the 
data set was opened.) The conversion 
module returns control to the base routine. 


The base routine again determines the 
form of channel program required, this time 
by checking fields in the IOB and in the 
DCB. The indicated module is given control 
and generates the proper channel program. 
If the extended search option has_ been 
specified, the channel program will reflect 
the search limits established in the 
DCBLIMCT field of the DCB. At the comple- 
tion of channel program generation, the 
base routine again receives control. 


After establishing 
the channel program, the base routine 
issues a request to the I/O supervisor by 
means Of the execute channel program (EXCP) 
routine. After the I/O supervisor has 
scheduled the request, control is returned 
to the base routine, which then returns 
control to the processing program. 


an expected end for 


ASYNCHRONOUS INTERRUPT COMPONENT 


The asynchronous interrupt (ASI) routine 
is the second main component of the founda- 
tion module. Before a request is consid- 
ered completed, certain processing func- 
tions must be performed by the foundation 
module. When the processing program is 
interrupted by the completion of an 
input/output operation, the I/O supervisor 
gives program control to the BDAM channel 
end appendage routine. The control rela- 
tionships involved at this time are shown 
in Figure 4. The ASI routine is scheduled 
by the supervisor after the BDAM channel 
end appendage module, IGGO19KU, has indi- 
cated the need for the ASI routine. The 
appendage module then returns control to 
the I/0 supervisor which, in turn, returns 
control to the supervisor. 


The main functions (see Chart 02) of the 
ASI routines are: 


e To determine the cause of interrup- 
tions. 
e To either initiate a restart of a 


channel program if necessary or branch 
either to error subroutines or to other 
processing modules (such as self- 
format, address conversion for relative 
block feedback, or address conversion 
for relative track feedback). 
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e If the request currently being process- 
ed is a request to write a block and if 
the dynamic buffer option has_ been 
specified, then the ASI routine will 
use the dynamic buffer module as a 
subroutine to free the buffer that has 
been allocated for the corresponding 
‘read' request. 


e If either the exclusive control option 
has been specified or a request to add 
new blocks of variable or undefined 
length has been specified, the ASI 
routine uses the exclusive control 
module either to place blocks ona 
queue or to remove blocks from a queue. 

e To release the request's IOB to _ the 
pool of I0OBs. (This function is per- 
formed by the check module if both a 
CHECK macro instruction is encountered 
and the DCB macro instruction specifies 
the check function.) After the IOB has 
been released, the request is posted as 
complete by means of the post routine, 
and control is returned to the supervi- 
sor. 


For each request, only those functions 
that are applicable are performed. 


ERROR COMPONENT 


The third major component of the founda- 
tion module consists of error routines both 
for processing invalid requests and for 
processing errors resulting from abnormal 
completion of a request. Figures 3 and 4 
indicate the error-processing functions. 


Invalid Requests 


Invalid requests are based upon differ- 
ences between the parameters specified in 
the DECB related to an individual READ or 
WRITE macro instruction and the parameters 
specified in the DCB at the time it was 
opened for processing with BDAM. Invalid 
requests can occur in the base routine of 
the foundation module, in the module for 
converting a relative track address to an 
actual address, in the moduie for convert- 
ing a relative block address to an actual 
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address, and in the module for generating a 
write-type channel program to add a _ block 
to a data set of fixed-length (or 
preformatted) records. 


When an invalid request is encountered, 
an error routine releases the IOB associat- 
ed with the request, posts an indication in 
the DECB that an invalid request has 
occurred, and returns control to the pro- 
cessing program. 


Abnormal Completion of a Request 


There are two situations in which abnor- 
mal completion of a request is related to 
BDAM. The first situation results from 
device errors. Errors included in this 
category are those relating either to the 
actual input/output devices and control 
units or to end-of-data-set conditions 
(which are received by the channel end 
appendage module as unit exception 
conditions). An error condition also 
results from not finding a dummy record in 
the case of a request to add a fixed-length 
block to an existing data set. An indica- 
tion of abnormal completion is established 
when the I/O supervisor enters the excep- 
tional end routine of the BDAM channel’ end 
appendage module, IGG019KU. 


The second situation can occur when a 
request is given to write a new block whose 
length is either variable or undefined. If 
it is determined that there is no available 
Space in which to add the new block, a BDAM 
routine sets an indicator to inform the 
processing . program so _ that appropriate 
action may be taken. 


When an abnormal completion is encoun- 
tered, the error routine releases’ the 
related IOB to the IOB pool associated with 
the data control block, posts an indication 
of the type of error and an indication of 
the completion of the request, and returns 
control to the supervisor. 


Note: The IOB is released to the IOB pool 
by the check module if applicable. (Refer 
to the section “Asynchronous Interrupt Com- 
ponent.") 


et 
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ADDRESS CONVERSION 


If the user specifies either relative 
track or relative block addressing, one of 


the BDAM relative address conversion 
modules is used. Each conversion module 
initiates transformation of the user's 


block address specification into an actual 
device location for the block so that the 
channel program can use the location when 
searching for the block. If the block 
address is given in terms of a _ relative 
track position, the relative track conver- 
sion module (IGG019KC) is used. If the 
address of a block is given as a relative 
block number within a data set, one of the 
two relative block conversion modules 
(IGGO19KE or IGG019KF) is used. If 
required, an address conversion module is 
loaded into main storage by the BDAM open 
executor phase 2 module at the time the 
data control block is opened. 


RELATIVE TRACK CONVERSION (MODULE IGG019KC) 


The relative track conversion module, 
IGGO019KC, is entered from either the base 
component or the ASI component of the 
foundation module. (See Figures 3 and 4.) 
Entry is from the base component if the 
purpose is to initiate a conversion from a 
relative track address to an actual device 
address. Entry is from the ASI component 
if the purpose is to initiate a conversion 
from a block's actual device address toa 
relative track address. The latter conver- 
sion is for purposes of feedback if speci- 
fied by the user. 


Entry From Base Component: The actual 
converting of track addresses is done by a 


conversion routine (referred to as the 
convert-to-actual routine) of the basic 
partitioned access method (BPAM). (Refer 
to the publication IBM System/360 Operating 


System: Sequential Access Methods, Program 
Logic Manual.) This routine is resident in 


main storage. When the BDAM conversion 
module gives control to the BPAM routine, 
it supplies the address of the location at 
which the actual address is to be placed 
(it is placed in the IOBSEEK field for use 
by the channel program), the relative track 
number that the user has indicated in the 
blkref field of the request macro instruc- 
tions , and the address of the DEB so_ that 
the BPAM routine can refer to the actual 
extents in the DEB. 


The DEB extents contain the cylinder and 
track information for the various sections 
of the data set (which is stored ona 
direct access device); from the extents, 
the BPAM routine obtains the actual start- 


ing address of each extent and the number 
of tracks in each extent. From this infor- 
mation, the BPAM conversion routine derives 
the actual address of the block whose 
address is to be converted. This address 
is then placed in the specified location 
(i.e., IOBSEEK), and the BPAM routine 
returns control to the BDAM relative track 
conversion module, which gives control to 
the base component of the foundation 
module. 


If the extended search option has_ been 
specified, the foregoing procedure is used 
to determine the actual address of the 
upper limit of the search. The starting 
track address and the number of tracks to 
be searched (as specified in the LIMCT 
parameter of the DCB macro instruction) 
enable the search limit to be computed. 
This limit is placed in the IOBUPLIM field 
of the IOB. 


Entry From ASI Component: The ASI routine 
receives program control after the channel 


program ends. If the user requests rela- 
tive track feedback, the ASI routine gives 
control to the BDAM relative track conver- 
sion module, which gives control to another 
resident BPAM conversion routine (referred 
to as the convert-to-relative routine). 
The BDAM module gives the BPAM routine both 
the address of the location of the actual 
block address (i.e., the address of 
IOBSEEK) and ,the address of the DEB. After 
the BPAM routine completes the address 
conversion and places the converted address 
in a parameter register, program control is 
returned to the relative track conversion 
module. This module stores the relative 
track address in the blkref area of the 
processing program and gives control to the 
ASI routine. 


RELATIVE BLOCK CONVERSION (MODULES IGG019KE 
AND IGG019KF) 


Each of the relative block conversion 
modules is entered from the foundation 
module to initiate the conversion of a 
relative block address to an actual device 
address. The data control block is exam- 
ined to determine if track overflow has 
been specified. If it has not been speci- 
fied, module IGGO19KE is used. If it has 
been specified, module IGG019KF is used. 
(See Figure 3.) In either case, the actual 
conversion requires two routines. The 
first routine is a BDAM routine that con- 
verts a relative block address to a rela- 
tive track address, and the second routine 
is a BPAM routine that converts a relative 
track address to an actual track address. 
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To convert relative block addresses to 
relative track addresses, the BDAM modules 
use information from the relative extent 
areas of the DEB. For each actual extent 
area in the DEB, there is a relative extent 
area whose fields (or field, if track 
overflow is specified) contain information 
related to a specific actual extent. One 
field contains the number of blocks ona 
track for the device used, and the other 
field contains the number of blocks in the 
actual extent. If track overflow is speci- 
fied, the first of these two fields is not 
present. 


Track Overflow Not Specified (Module 
IGG019KE) 


To determine the relative track address 
from a relative block number given in the 
blkref field of a READ macro instruction, 
module IGGO19KE goes through a repeating 
cycle of reducing the relative block number 
by a given number of blocks and recording 
the corresponding number of tracks as fol- 
lows. 


The relative block number reduction 
process involves successively subtracting 
the number of blocks in each extent of the 
data set until an extent that contains more 
blocks than needed to reach the blkref 
field value is reached. For each full 
extent that can be subtracted, the number 
of tracks in the extent is added to a 
cumulative total of tracks representing 
previously subtracted extents. The first 
full extent that cannot be subtracted as 
indicated is referred to as ae terminal 
extent. 


When the terminal extent is reached, 
there will remain a number of blocks’ equal 
to the difference between the blkref value 
and the number of blocks already subtract- 
ed. This remaining number is divided by 
the “blocks per track" field of the DEB. 
The quotient in this division is the number 
of full tracks to be added to the cumula- 
tive total of tracks. The remainder in 
this division represents the number of 
blocks from the next track (called the 
terminal track) that are required to reach 
the value indicated by the blkref parame- 
ter. 


The relative track address, in the form 
of a TTR address (where TT is the relative 
track number and R is the block number of 
track TT), is composed of (1) the sum of 
the tracks required from all extents (if 
any) up to the terminal extent plus the 
number (the quotient in the above division) 
of full tracks required from the terminal 
extent and (2) the number of remaining 
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blocks § (if any) required from the 
(terminal) track following the last full 
track. 


Control is then given to the BPAM 
convert-to-actual routine that is resident 
in main storage. This is the routine 
required for the relative track address 
conversion process, and it requires the 
same information that was needed for the 
relative track conversion process. (Refer 
to "Relative Track Conversion.") 


The BPAM conversion routine places’ the 
converted address in the IOBSEEK field of 
the IOB and returns control to the BDAM 
relative block conversion module, which 
then gives control back to the foundation 
module. 


In a manner similar to that described in 
the section “Relative Track Conversion," an 
extended search limit, if necessary, is 
computed for relative-block-addressing con- 
ditions. The actual address of this upper 
limit also is placed in the IOBUPLIM field. 


Following is an example of calculating a 
relative track address for the case of a 
data set without track overflow when a 
relative block number is given in the 
blikref parameter of a READ macro instruc- 
tions . 


Example 2: Assume the data set is con- 
tained in four extents identified as I, II, 
III, and IV. Let extent I contain 10 
tracks with 80 data blocks; extent II 
contain 14 tracks with 112 data blocks; 
extent III contain 8 tracks with 64 data 
blocks; and extent IV contain 12 tracks 
with 96 data blocks. (This assumes that 
the data set is on a device permitting 8 
data blocks to be placed on one track.) 
The information needed from the DEB for 
this data set can be summarized in Table 2 
below: 


Table 2. DEB Information for Example With- 
out Track Overflow 

ae Catan TRIG aE: Pipa CO RUNNIN RE mane | 
| DEB Field |Extent|Extent|Extent|Extent | 
| {| I | II | «Ir iv | 
}------------- }------ }------ }--—-- $------ { 
| Blocks per | 8 |} 8 {| 8 | 8 | 
| Track | | | | | 
}------------- t------ }------ $------ }-~---- 1 
| Tracks per | 10 {| 14 i 8 | 12 | 
| Extent { | | | | 
}------------- $------ +------ +------ +------ 1 
| Blocks per [|B,=80 |B2=112|B3=64 |B,=96 | 
| Extent | | | | 
bee er pO easel ene ts fee ere eco, J 


If the blkref field contains a_ relative 
block number of 284, the calculations to 
find the relative track address are indi- 
cated below: 


blkref value ~- By, = R, (remainder) 


The 80 blocks from Extent 
I are on 10 tracks 


284 - 80 = 204 


Ry - Bo = Ra 


The 112 blocks from Extent 
II are on 14 tracks 


204 - 112 = 92 


Ra = B3 = R3 


92 - 64 = 28 The 64 blocks from extent 


III are on 8 tracks 
R3 - 


28 - 96 < 0 


Since R, is less than zero, the full extent 
(IV) cannot be subtracted. Extent IV is 
called the terminal extent. The previous 
remaining value (R3z = 28) is divided by the 
blocks per track value (8) to give a 
quotient of 3 and a remainder of 4. The 3 
represents the number of tracks of the 
terminal extent that must be added to the 
sum of the underlined numbers of tracks 
from extents I, II, and III. The 4 rep- 
resents the number of data blocks that must 
be counted from the beginning of the termi- 
nal track. Thus, the relative track 
address (TTR) of the block in this example 
is equivalent to 35 tracks (the TT value) 
and 4 blocks (the R value) from the begin- 
ning of the data set. 


Track Overflow Specified (Module IGG019KF) 


To determine the relative track address 
from a relative block number given in the 
blkref field of a READ macro instruction, 
module IGGO19KF uses the overflow section 
of the DEB as well as the single field in 


each required relative extent area of the 
DEB. The track overflow option implies 
that overflow blocks may be present in an 
extent. For purposes of block addressing, 


the track on which an overflow block begins 
is considered to contain the block. The 
DEB information used for calculating the 
relative track address of an overflow block 
is contained in the following fields of the 
DEB: 


e Tracks per extent 
e Tracks per period 
e Blocks per period 
e Blocks per extent 


The process of converting a relative 
block number to a relative block address 
(in the TTR format) involves successively 
subtracting the number of blocks in each 
data set extent until an extent that con- 
tains more blocks than needed to reach the 
blkref field value is reached. For each 
full extent that can be subtracted, the 
corresponding number of full tracks is 
added to a cumulative total of tracks 
representing previously subtracted extents. 
The first full extent that cannot be sub- 
tracted as indicated is called the terminal 
extent. 


Upon reaching the terminal extent, the 
periods in that extent are considered as 
follows. The ‘blocks per period’ value is 
subtracted successively until reaching a 
period, the block count of which cannot be 
subtracted as indicated. This period is 
the terminal period. For each period for 
which the full number of blocks can be 
subtracted, the number of tracks is added 
to the cumulative total of tracks. 


The individual tracks in the terminal 
period are then added in successively until 
a track containing a number of blocks’ that 
is equal to or greater than the remaining 
number of blocks needed to equal the blkref 
value is reached. This track is the termi- 
nal track. The total of all the tracks 
(taken in considering full extents, full 
periods, and partial periods) and _ blocks 
(taken in considering the blocks on the 
terminal track in the terminal period) 
determines the relative track address cor- 
responding to the relative block number 
given in the blkref field. . 


After the relative track address hag 
been determined for a block where the track 
overflow specification exists, control is 
given to the BPAM convert-to-actual routine 
and processing proceeds as described for 
the no-overflow case. 


Following is an example of calculating a 
relative track address for the case of a 
data set having overflow blocks when the 
relative block number is given in the 
blkref field. 


data set is con- 
identified as MI, 


Example 3: Assume the 
tained in three extents 


II, and III. Let extent I contain 20 
tracks with 114 data blocks; extent II 
contain 10 tracks with 57 data blocks; and 
extent III contain 27 tracks with 153 data 
blocks. Further, assume that phase 3 of 
the BDAM open program has established that 
each period contains 3 tracks with a total 
of 17 blocks and that the blocks are placed 
on the tracks so that the first two tracks 
each contain 6 blocks and the third track 
contains 5 blocks. 
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The information needed from the DEB for 


this data set is summarized in Table 3 
below: 

Table 3. DEB Information for Example With 

Track Overflow 

PERSE ete ye ea 6 acerca peers! 5 Neier 

| DEB Field | Extent| Extent] Extent| 
| } I | Ir {| III | 
~----------------}------- }-------4--~----4 
|Tracks per Extent| 20 | 10 27 | 
-----------------}------- +-------}-------4 
{Tracks per Period| 3 { 3 | 3 | 
~---=-------------}------- }-------}------- 
|Blocks per Period| 17 { 17 a | 
ma eee ere a eae es oe 

{Blocks per Extent| B,=114| B2=57 | B3=153]| 
GRE ede a Ny eT EO opens tee eee y Sennen Ms is os ie J 


If the blkref field of a READ macro 
instruction contains a relative block num- 
ber of 217, the calculations to find the 
relative track address are indicated below: 


blkref value - B, = R, (remainder) 


217 - 114 = 103 The 114 blocks (from 
Extent I) are on 20 tracks 


R, - Bo = Ra 


103 - 57 = 46 The 57 blocks (from Extent 


II) are on 10 tracks 
Roa - B3 = Rs 
46 - 153 < 0 


Since Rs is less than zero, the full extent 
(III) cannot be subtracted. Extent III 
becomes the terminal extent. Now the per- 
iods in the terminal extent are considered. 


Let the periods of Extent III be 
nated as IIIa, IIIb, IIIc, etc. 
lations proceed as follows: 


desig- 
The calcu- 


Ra - IIIa = R3 

46 - 17 = 29 The 17 blocks (from period 
IifIa) are on 3 tracks 

Rs - IIIb = R, 

295 17 = 12 The 17 blocks (from period 


IIIb) are on 3 tracks 


R,- IIIc = R, 


i2 = 17 < 0 


Since R_ is less than zero, the full period 
(IIIc) “cannot be subtracted. Period IIIc 
becomes the terminal period. Now, the 
blocks on the tracks in the terminal period 


20 


are subtracted to arrive at the final 
required number of equivalent tracks and/or 
blocks to equal the relative block number. 
In this example, the 12 remaining blocks 
(the R, value) are equivalent to one track 
(of 6 blocks) plus six blocks (on the 
terminal track). 


The total number of tracks plus) addi- 
tional blocks thus is equal to the sum of 
the underlined numbers of tracks in the two 
full extents (I and II) and the two full 
periods (IIIa and IIIb) in extent III plus 
the one track and 6 blocks from period 
IIIc. This value is 37 tracks and 6 
blocks, giving a TTR value that can be used 
by the BPAM routine to obtain an actual 
address for the block. 


FEEDBACK FOR RELATIVE BLOCK ADDRESSING 
(MODULES IGG019KG AND IGG019KH) 


The feedback modules, IGGO019KG and 
IGGO19KH, are used when feedback and rela- 
tive block addressing have been specified. 
(See Figure 4.) Entry to the proper module 
is from the ASI routine at the completion 
of a channel program. The actual address 
of the block was obtained when the channel 
program made access to the block. 


The actual device address of the block 
is given to the BPAM convert-to-relative 
routine by the feedback module. The _ rela- 
tive track. address determined by the BPAM 
routine is given to the appropriate BDAM 
feedback module. Using information that is 
contained in the actual extents, the rela- 
tive extents, and, if track overflow has 
been specified, the overflow section of the 
DEB, the feedback module constructs the 
relative block address for the block and 
places the result in the blkref area speci- 
fied in the DECB. The method used in 
obtaining the relative block number is 
basically a reversal of the technique used 
to convert to an actual address. The 
feedback module then gives program control 
to the ASI routine. 


CHANNEL PROGRAMS FOR BDAM 


To perform the input and output opera- 
tions required by BDAM processing, several 
channel programs are available. For each 
request to read or write a block, the 
appropriate channel program is constructed 
dynamically when the base routine of the 


foundation module gives control to a BDAM 
channel program generating module. (See 
Figure 3.) Appendix C contains the actual 


channel programs that are generated. 


The foundation module uses parameters 
specified in the DCB and in the individual 
request macro instruction to determine 


which channel program is to be constructed. 
The type field of the IOB is tested for 
this purpose. The channel command words, 
of which the channel programs are con- 
structed, contain the following types of 
operation codes: write information, read 
information, search for equal argument, 
transfer in channel, and track seek. The 
channel programs permit BDAM to read or 
write blocks based on either a key ora 
block identification search argument. 


As a channel program is constructed, it 
becomes a logical part of the IOB associat- 
ed with the request. (The structure of an 
IOB as it relates to BDAM is given in 
Appendix A.) There are three categories of 
channel programs: update programs, format 
programs, and the verification program. 


UPDATE PROGRAMS (MODULES IGGO019KI, 
IGGO19KK, AND IGG019KW) 


The update programs are those that read 
or write information for purposes other 


nel program generating module by the foun- 
dation module. 


Basically, there are three BDAM channel 
programs available for reading or for 
updating an existing block. Each channel 


program can take one of two forms depending 
on whether it is generated in response to a 
read request or in response to ae write 
(update) request. These forms are shown in 
Table 4. The search arguments indicated in 
this table correspond to the fields of a 
block as it appears on a direct-access 
storage device. (See Figure 5.) If the 
extended search option has been specified, 


module IGGO019KW modifies the channel pro- 
gram that has been generated by module 
IGGO19KI, to search additional tracks or 


blocks beyond that which is specified in a 
READ or a WRITE macro instruction. 


For channel programs to satisfy a write 
request for which the write-validity-check 
option has been specified, control is given 
to the write-verify module, IGG019KQ, at 
the completion of the channel-program gen- 
erating function of the appropriate update 
program module. After generating the veri- 
fication channel program, the write-verify 


than adding a new block to an existing data module returns control to the foundation 
set. Control is given to the proper’ chan- module. 
Table 4. Channel Programs for Reading or Writing an Updated Block 
OSes eae a a aa aL ER moa mr 
| Channel Program | | Extended Search | Generating | 
| Form | Search Argument {| Option Specified | Module (s) | 
}--------------------- }---~-~-------=------- {------—~-—---------- }--------------------- { 
| Read Data or | Key Field | No | IGGO19KI | 
| Write Data | | | | 
}--------------------- fae rename nnnnn frwaw nn nnnn nan nnnnn a= }----------------=---- { 
| Read Data or | Key Field | Yes | IGGO019KI and | 
| Write Data | | | IGGO019KW | 
}--------------------- fomnnne nnn e nanan nnn fre {-----—------~-------- { 
| Read Data or | Block ID of | Not a Factor | IGG019KK | 
| Write Data | Count Field | | | 
bei A os a Of Ce a Sa Pr De See ee i Cee a ne Oe ee ae aera RET ae J 
a age eB eT a ge ee ae ey ae a 1 
| | 
| aa a bt aaa sa ase a 7 | 
| | Ii lI | | 
| | COUNT FIELD {| KEY |] DATA | | 
[0 free enann=- 1-------- y7~-------- 4\ [| | | 
| | Block ID | Key | Data 11 i] | | 
| j (CCHHR) | Field | Field || FIELD || FIELD | | 
| | | Length {| Length {| tI | | 
| Liss are Lesaioccc Pie ks bg eee eee OB ae ee ee J r 
| < 5 bytes > <1 byte> <2 bytes> | 
{ | 
| CCHHR gives the physical position of the block on the device. | 
| The Key Field Length specification may be from 0 to 255 bytes. | 
| The Data Field Length specification may be from 0 to 32760 bytes. | 
i | 
bo eee ee a ine See Se eee eae ema J 
Figure 5. Structure of a Block on a Direct-Access Storage Device 
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Each channel-program generating module key field or on the count field of a block, 
returns control to the foundation module's and they may or may not require the verifi- 


base component after the last channel com- cation channel program (generated by module 
mand word has been generated and placed in IGG019KQ). The pre-format and self-format 
the IOB for the request. Chart 03 summari- programs are respectively generated by 
zes the flow of control among BDAM modules either the pre-format modules or the self- 
for updating (or reading) information. format modules, depending on the _ block 


format of the data set. 


Table 5 shows the factors that determine 

which format modules are required to 

FORMAT PROGRAMS generate the format channel programs. Note 
that when the extended search option is 

specified for fixed-length blocks,. two 

There are three BDAM format’ channel modules are required. The second module 
programs. These programs are used for listed is given control by, and returns 
writing a new block from main storage onto control to, the first module. The function 


a direct-access device. For adding fixed- of the second module is to modify the . 
length blocks to an existing data set, two channel program generated by the first 
of the three channel programs are module. The foundation module gives con- 
available. The choice of which one will be trol to either IGGO19KO or IGG019KM 
used depends on whether the extended search (depending on the block format), and when . 
option has or has not been specified. the channel programs have been generated, 
Since the block length is known or prede- the format module returns control to _ the 


termined, these channel programs are called foundation module. 
pre-format programs. 


If the processing program specifies 
adding either variable-length blocks or 
blocks of an undefined length to an exist- 
ing data set, the remaining format channel Pre-Format Channel Programs 
program is required. When the extended (Modules IGG019KO and IGG019LA) 
search option is specified, this channel 
program is repeated as many times as neces- 
Sary until either track space for the The pre-format channel programs are used 
record is found or the search limit is when a new fixed-length block is to be 
reached. Since BDAM itself must establish added to an existing data set. In order to 
the space requirements for writing these add fixed-length blocks, the user must have 
blocks, these channel programs are called initially placed his data blocks on the 
self-format programs. direct-access device by means of the basic 
sequential access method (BSAM) write rou- 
tine for creating a direct organization 
The format channel programs are some- data set. As blocks were placed on the 
times referred to as ‘write-add* programs direct-access device, dummy records may 
to distinguish them from the write programs have been provided to allow the BDAM chan- 
described as update programs. nel program to search for an area in which 
to place a new block. A dummy record is 
one in which the first byte of the key 
As with the update channel programs, the field is a hexadecimal FF, and the first 
format channel programs incorporate channel byte of data has a value indicating the 
command words for searching either on the position of the dummy record on the track. 


Table 5. Requirements for Channel Programs to Add New Blocks to an Existing Data Set 


i aaa a a a ey Met ee ae oe Sa cate a cad aaa he a a aa earn a aay | 
| | Channel Program | Extended Search | Generating | 
| Block Length | Format | Option Specified | Module (s) | 
}----------~--+-------~ anna anna nnn }--------------------- }--------------------- : 
| | | No | IGG019KO | 
| Fixed | Pre-format }--------------------- +------------~--------- , 
{ | i Yes i IGG019KO, | 
| | | | IGGO19LA | 
}--------------------- }--------------------- $--------------------- }--------------------- : 
| Variable or | Self-format | No | IGG019KM | 
| Undef ined | }---------------------+4--—--------~----------j 
{ | | Yes | IGG019KM | 
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all 


Without Extended Search Option: If the 
extended search option has not been speci- 


fied, the pre-format channel program is 
generated by module IGG019KO. This module 
is entered from, and returns control to, 
the foundation module's base component. 
The module constructs the necessary channel 
command words and, by incrementing a base 
address in the IOB, positions the fields of 
the channel command words as they are 
developed. 


The channel program first searches an 
indicated track for a dummy record. This 
search starts at the first block encoun- 
tered on the proper track. If a dumny 
record is not found on the indicated track, 
the search is not satisfied. An indication 
of ‘no-space-found' is then given to the 
processing program. This indication 
appears in the DECB. The search is suc- 
cessful if a dummy record is encountered. 


After the key field of a dummy record 
has been found, the first byte of the data 
field is read into the IOB to provide the 
position of the dummy record on the track. 
The same dummy record is next located by a 
search on the ID portion of the count 
field. The new block key and data fields 
can then be written to replace those of the 
dummy record. 


With Extended Search Option: If the 
extended search option has been specified, 


the pre-format channel program is generated 
by modules IGG019KO and IGG019LA. The 
function of module IGG019LA is to modify 
the channel program generated by module 
IGG019KO so that the search for a dummy 
record will extend across multiple tracks 
(up to the limit specified in the IOBUPLIM 
field of the IOB). If the extende@ search 
comes to an end and a dummy record is not 
found, the procedure is the same as de- 
scribed for the case without the extended 
search option. 


If a dummy record is found, the search 
is successful and the dummy record's posi- 
tion is read into the IOB as_ before. The 
channel program then continues as in the 
case without the extended search option. 


If the block that is being written by 
the request must be verified (because of an 
option specified in the DCB macro- 
instruction), the appropriate pre-format 
channel program iS enlarged to include 
additional channel command words. Module 
IGG019KQ is given control to perform this 
function. (Refer to "Verification 
Program.") 


Self-Format Channel Programs 
(Modules IGGO19KM and IGG019KY) 


The self-format channel programs are 
used when new blocks of either undefined 
length (format U) or variable length 
(format V) are to be added to an existing 
data set. As with fixed-length records, 
the basic sequential access method's write 
routine for creating a direct-organization 
data set must have been used to initially 
place the data blocks on the direct access 
device. When the data set is initially put 
on the direct access device, a capacity 
record (block 0) is also placed on each 
track. The capacity record contains both 
the ID of the last block on the track and 
the number of usable bytes remaining on the 
track. These are the available bytes that 
may be used for new blocks. Figure 6 
illustrates the data portion of the capaci- 
ty record. 


Cee ie 
| ID of [Usable bytes | Unused | 
| last block |remaining on | | 
| | track | | 
ae ee a Mt oe at Bah a So J 


<---5 bytes--> <--2 bytes--> <---1 byte---> 


Figure 6. Data Field of a Capacity Record 
for a BDAM Data Set 
The foundation module gives control to 


BDAM module IGG019KM to generate the chan- 
nel program for both format U and format V 
records. The channel program consists of 
(1) one section that reads the capacity 
record from the indicated track into main 
storage and (2) another section that writes 
the new block and updates the capacity 
record to reflect inclusion of the new 
block "on the track. Generation of the 
self-format channel program involves moving 
constants representing elements of channel 
command words into assigned positions of 
the request's IOB to form the _ required 
channel command words. If record verifica- 
tion is required, the self-format channel 
program is enlarged by module IGG019KQ to 
include the verification program channel 
command words. 


The last channel command word of the 
section of the channel program that reads 
the capacity record does not include a 
command chaining flag. This permits the 


I/O supervisor to give control to the 
channel end appendage module after the 
capacity record has been read. The appen- 


adage module then branches to a supervisor 
routine to schedule the ASI routine. 
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In the performance of two or more tasks, 
concurrent requests to add a block to the 
same track on a direct-access device may be 
made. All but one of these requests 
(called ‘write-add' requests) must be 
placed on an inter-task queue to prevent 
undesired interference. This interference 
would result from other requests obtaining 
the same track capacity record for interro- 
gating and updating before a first request 
was finished with it. Concurrent requests 
for the same track may also occur in the 
performance of a single task. 


When the ASI routine (1) (numbers in () 
refer to points indicated on Figure 6A) 
gets control after the track capacity 
record has been read for a write-add 
request, it, in turn, gives control to the 
exclusive control module IGG019LG (2). 
Module IGG0O19LG either places the record on 
an inter-task queue by using the ENQ macro 


instruction (3) or places the IOB for the 
record on the unposted queue (4). (The 
functions of the exclusive control module 


are described more fully in the _ section 
“Exclusive Control.") In either case, con- 
trol is then given to the supervisor. 

After the 


channel program reads the 


‘capacity record in connection with a given 


write-add request, the supervisor 
gives control to the ASI routine (5). 
ASI routine then gives control to module 
IGG019KM so that the information in the 
capacity record can be tested (6) to deter- 
mine if the block to be written will fit on 
the indicated track. 


again 
The 


If the track can contain the new block, 
calculations are made to update the capaci- 
ty record. The channel program is then 
modified to reflect the correct search 
argument, and an EXCP macro instruction is 
issued to write the new block and the 
updated capacity record. Module IGG019KM 
then gives control to the exclusive control 
module (7). If the new block will not fit 
on the track, control is given to the 
exclusive control module immediately. 


If the unposted queue does not contain 
an IOB waiting for the capacity record that 
was just updated, the capacity record is no 
longer needed for the performance of the 
current task. Module IGG019LG issues a DEQ 
macro instruction to release the record to 
other tasks that may require it, and con- 
trol is given to module IGGO19KM (8). If 
an IOB for this capacity record is on the 
unposted queue, both the address of the IOB 
and program control are given to module 


IGGO19KM. 


The self-format module determines wheth- 
er the block was placed on the track (i.e., 
if the track had room for the block). If 
it was, and if the unposted queue contained 


another IOB for the same capacity record 
(9), the value in the IOB 
(IOBDBYTR...see Appendix A) that contains 
the number of remaining bytes on the track 
is moved from the IO0OB of the current 
request to the IOB of the next request for 
this same capacity record. In this situa- 
tion, the capacity record is still retained 


as a result of the ENQ macto instruction 
issued for the current task. Therefore, 
the self-format module can immediately 


begin processing this next request at the 
point of determining whether the block will 
fit on the track (6). If the block was 
placed on the track and if the _ unposted 
queue did not contain any more IOBs for 
this capacity record, module IGG019KM gives 
control to the supervisor (10). 


If the block was not placed on the track 
because of space limitations, and if the 
extended search option has not been speci- 
fied, an indication that no space is avai- 
lable is placed in the IOB (11). The ASI 
routine then gets control to post the 
request as complete and to place a no- 
space-found indication in the DECB (12). 
The self-format module then determines if 
the unposted queue contained another IOB 
for the same capacity record (13) and 
either returns control to the supervisor or 
moves the value in the IOBDBYTR field and 
continues as described in the preceding | 
paragraph. "€ 


If the block has been kept from the 
track because of space limitations but the 
extended search option has been’ specified, 
control is given to the self-format 
extended search module IGG019KY. This 
module updates the current track address by 
one and proceeds according to the condi- 
tions given in the following paragraphs: 


A. If the updated track address is equal 
to the search limit indicated in the 
IOBUPLIM field of the I0B, the no- 
space-found indication is set for this 
request (14). Control then returns to 
the self-format module and processing 
continues as if the extended search 
option had not been specified. 


B. If the updated track address is beyond 
the current extent, control is given 
to the BDAM end-of-extent module, 


IGGO19LC. This module determines if 
more extents are available for 
searching. There are two possibili- 


ties for consideration. 


1. If there are more available 
extents and if the upper limit of 
the search has not been reached, 
the address of the first track of 
the next extent 
self-format module. Since access 
to this new track may be required 


field’; 


is given to the 3) 


in the performance of other tasks, 
it is necessary to give control to 
the exclusive control module at 
this point (2). The exclusive 
list is checked for the occurrence 
of the new track address and pro- 
cessing continues as_ previously 
described (in the beginning of 
this section) for the first capac- 
ity record. 


2. If- either the search limit has 
been reached or there are no more 
available extents, the procedure 
is as described for condition (A). 


C. If the updated track address is within 
the current extent and the search 
limit has not been reached, the pro- 
cessing of condition (B1) is  contin- 
ued, commencing with giving control to 
the exclusive control module. 


Where applicable, the procedures described 
in the preceding paragraphs are repeated as 
Many times as necessary until either track 
space on which to write the block is found 
or the search limit is reached. 


If the unposted queue contained another 
IOB for the same capacity record (point 9 
on Figure 6A), processing of that IOB then 
continues from point D in Figure 6A. 


VERIFICATION PROGRAM (MODULE IGG019KQ) 


If the processing program specifies the 
write-validity-check option in the DCB for 
the data set, the write-verify module, 
IGGO19KQ, is used to generate additional 
channel command words to verify information 


that has been written by a write-type 
channel program. These channel command 
words are added to the existing channel 
program. 


If required, the BDAM open executor 
program brings the write-verify module into 
main storage at the time the data set is 
opened. This module is entered from the 
module that generates the particular type 
of writing channel program required by the 
request macro instruction. As data blocks 
are written, the control unit develops a 
check code for each field of the block. 
This code is based on the information that 
is written in the field. As each field is 
written, the check code developed for it is 
appended to it. Verification is accom- 
plished by reading back the block to be 
checked to permit the control unit to 
recompute the check codes. The control 
unit then compares the check code written 


on the track with that developed by the 
read-back. If the two codes are not equal, 
a data check indication is set. The skip 
flag-command-code is set to 1 (on) in the 
last channel command word of the verifica- 
tion program so that the data that is read 
back is not placed into main storage. 


The write-verify module returns control 


to the base component of the foundation 
module. 
APPENDAGES 


The basic direct access method contains 
appendage modules to which program control 
is given at various stages during the 
execution of a read or a write request. 
The combined functions of the _ several 
appendage modules are to make tests, to set 
switches, to schedule the BDAM ASI routine, 
and to obtain new extents for extended 
search operation. 


When the DCB is opened, phase 2 of the 
BDAM open executor routine issues the LOAD 
macro instruction to load the appendage 
modules into main storage and places’ the 
addresses of the modules into an appendage 
list, which phase 1 has built in an area of 
protected main storage. (See Figure 1.) 
This list, which is also referred to as the 
IOS Appendage Address Table, is located in 
subpool 254 of the supervisor queue area. 


The BDAM program uses three appendage 
modules: the start I/O appendage module, 
the channel end appendage module, and the 
end-of-extent appendage module. (See Chart 
01.) 


The start I/0 appendage module and the 
channel end appendage module are _ entered 
from the I/O supervisor and return control 
to the I/O supervisor. The end-of-extent 
appendage module may be entered from either 


the BDAM self-format module or the I/0 
supervisor. On returning from the end-of- 
extent appendage module, control may be 


given to either the BDAM self-format module 


or the I/O supervisor. 


START I/O APPENDAGE (MODULE IGG019KS) 


The BDAM 
IGG019KS, 


Start I/O appendage module, 
is placed in main storage if the 
dynamic buffering option has been 
specified. This module is entered from the 
I/O supervisor before a channel program is 
initiated. (See Figure 7.) 
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a Request 


Buffer Needed 


When a request with the dynamic buffer 
specification is ready to be executed, I/0 
supervisor gives control to the BDAM start 
I/O appendage module. This module deter- 
mines if a buffer has already been assigned 


to this request or if it is necessary to 
obtain a buffer from a buffer queue. If a 
buffer must be obtained, module IGG019KS 


gives control to the dynamic buffer module, 

IGGO19LE. If the buffer request does not 

have to be placed on a queue by the dynamic 
ss buffer module, the start I/O appendage 
module will receive control after a buffer 
has been allocated. The request is then 
ready for execution, and control passes to 
the I/O supervisor for channel program 
execution. - 


CHANNEL END APPENDAGE (MODULE IGG019KU) 


When a channel program is terminated, 
either normally or abnormally, the I/O 
supervisor gives control to the channel end 
appendage module, IGG019KU. (See Figure 
4.) This module is always placed in main 
storage by the BDAM open executor phase 2 
module. There are two general sections to 
the channel end appendage module. The 
sections are entered under the conditions 
described in the following paragraphs: 


IGGOI9LE 


Dynamic 
Buffering 


Get Buffer if Dynamic 
Buffering Specified 


Buffer not See Text 


Available 


~--—-—--—» Main Flow of Control 
——— Functions Performed 
——— ——® Linkage to Routine to Perform Functions 


10S Input/Output Supervisor 


Among Processing Program, I/O Supervisor, and BDAM for Executing 


The first section 
the following 


Entry to First Section: 
is entered under one of 


conditions: 


e A channel program terminates normally. 


e A channel program encounters a unit 
exception condition, which is inter- 
preted by the BDAM program as an end- 


of-data-set condition. 


The execution of a channel program 
results in a block length different 
from that specified in the READ or 
WRITE macro instruction. 


If the channel program terminated 
normally, the channel end appendage module 
schedules the BDAM asynchronous interrupt 
routine and then gives control to the I/0 
supervisor. 


Note: To schedule the ASI routine, the 
channel end appendage module branches’ to 
the exit effector routine of the task 
supervisor. (Refer to the publication IBM 


System/360 Operating System: MVT Supervi- 


Sor, Program Logic Manual.) The exit 
effector routine then schedules the ASI 


routine and returns control to the channel 
end appendage module. 
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For an end-of-data-set condition, the 
channel end appendage module sets indica- 
tors in the IOB, schedules the BDAM asyn- 
chronous interrupt routine, and returns 
control to the I/O supervisor. (Refer to 
preceding note.) 


If the 
entered 


channel end appendage module is 
because of an incorrect-length 
indication (given in the IOB when the 
number of bytes read or written is not 
equal to the number of bytes specified in 
the channel program), a test is made to 
determine the type of request being pro- 
cessed. Three cases are possible: 


e If the request was a read request fora 
variable-length block, the length of 
the block being read is compared to the 
number of bytes of data actually read 
by the channel program. (The length of 
the block is specified by the first two 
bytes of the data field of the block 
reaa into the designated area. The 
number of bytes actually read is deter- 
mined from a calculation involving the 
bytes-remaining field of the channel 
status word.) If the length values are 
equal, the incorrect-length indication 
is set to 0 (off), and the ASI routine 
is scheduied by the exit effector rou- 
tine. Control is then returned to the 
I/O supervisor. 


e If the request was a read request for 
format-U records, the incorrect-length 
indication is set to 0 (off), and the 
ASI routine is scheduled by the exit 
effector routine. Control is then 
returned to the I/O supervisor. 


e If the request was a write request or a 
read request for format-F records, or 
if the block lengths in the first case 
are unequal, the ASI routine is not 
scheduled, the incorrect-length indica- 
tion is left set at 1 (on), and the 
channel end appendage module gives con- 
trol to the I/O supervisor. 


Entry to the Second Section: The second 
section of the channel end appendage module 


is entered when either a device-type error 
or a permanent error has been encountered. 
If a device error occurs, the I/O supervi- 
sor receives control and uses a standard 
IBM error-recovery procedure. If the error 
condition remains after this procedure, the 
error is classed as a permanent error. 


For permanent errors, the channel end 
appendage module sets an indicator in the 
IOB, schedules the BDAM asynchronous inter- 
rupt routine, and returns program control 
to the I/O supervisor. 
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END OF EXTENT APPENDAGE (MODULE IGG019LC) 


The BDAM end-of-extent appendage module 
is required if the extended search option 


has been specified in the DCB macro 
instructions . At the time the data set is 
opened, phase 2 of the BDAM open executor 


program determines the need for this. end- 
of-extent module and loads it if necessary. 
There are two extended-search-type 
Situations that require this module. In 


one situation, the module functions as an 
I/O supervisor appendage. In the other 
Situation, the module appears as a BDAM 


routine without supervisory functions. 


Supervisory Mode 


The I/O supervisor gives control to the 
BDAM end-of-extent module when a channel 
program comes to the end of a data set 
extent while searching for a block to be 
read or written or while searching for a 
dummy record in which to write a new 
pre-format type block. Under either of 
these situations, module IGG019LC estab- 
lishes the address of the next extent to be 
searched. Note that if a search has’ begun 
at some point other than the beginning of 
the first extent in the DEB, the address of 
the next extent may, at some point in the 
search, become that of the first extent. 


If the search limit (as determined from 


the LIMCT parameter in the DCB macro 
instruction) is not in this next (or new) 
extent, the end-of-extent module either 


returns control to the I/O supervisor to 
restart the channel program using the new 
extent or, if the new extent refers to 
another device, indicates the need for the 
BDAM asynchronous interrupt routine to re- 
schedule the channel program using a search 
address in the new extent. 


Note: The search limit is found in the 
IOBUPLIM field of the IOB. The limit is 
defined as the first track beyond the last 
actual track that may be searched for the 


given data set. 


If the search limit is in this new 
extent but the new search address is not 
equal to the search limit, the channel 
program will be rescheduled by either the 
I/O supervisor or the ASI routine as 
before. 


If the search limit is in this extent 
but the new search address equals’ the 
search limit, the search has ended unsuc- 
cessfully. An indication is then set to 


show that either no space was found or no 
block was found, and control is given to 
I/O supervisor, which, in turn, will go to 
the abnormal end component of the BDAM 
channel end appendage. 


Non-Supervisory Mode 


The BDAM self-format extended search 
module may at some time, in the process of 
establishing search addresses, recognize 
that the end of a given data extent has 
been reached. If this happens, the extend- 
ed search module gives control to the 
end-of-extent module. 


As when in the supervisory mode, module 
IGGO19LC determines the availability of 
other extents to be searched, establishes a 
new search address, and determines whether 
or not the search limit has been reached. 
If the search limit has not been’ reached, 
the end-of-extent module uses’ the new 
search address related to a new extent and 
reschedules the channel program (to read in 
the capacity record of the next track) and 
then gives control back to the self-format 
module. 


If the search limit has been reached, an 
indication that no space has been found is 
placed in the request's IOB. When the 
request is posted, this indication is 
placed in the DECSDECB field of the DECB. 


EXCLUSIVE CONTROL (MODULE IGG019LG) 


If a programmer has specified that the 
exclusive control feature be applied to 
blocks that are read and that may or may 
not be subsequently written, the ASI rou- 
tine gives control to module IGG019LG to 
handle both the block queuing and the block 
dequeuing that is required with this fea- 
ture. 


In addition, 
place records on a queue when the process- 
ing program encounters a request to add a 
new block of either variable-length records 


or records of undefined length. (Refer to 
Chart 04.) 
With exclusive control in effect, a 


given block may not be updated (or other- 
wise acted upon) by processing associated 
with other requests until exclusive control 
for that block has been removed. If the 
MACRF operand of a DCB macro instruction 
for BDAM contains the exclusive control 
specification, the following BDAM macro- 
instructions require the exclusive control 
module: 


module IGGOIi9LG is used to 


read-exclusive list, 


e READ (with exclusive control 


specification). 


an 


e WRITE (with an exclusive control 


specification). 
e RELEX. 


Until the exclusive control module is 
first given control, the read-exclusive 
list (see Appendix A) consists of an 
80-byte segment of main storage obtained by 
phase 1 of the BDAM open executor program. 


This segment contains space for nine 
entries, each entry consisting of the UCB 
pointer and the device address of a _ block 


for which exclusive control is required. 
When more than nine entries are needed on 
the read-exclusive List, additional main 
storage is Obtained in increments of 
80-byte segments, each of which can contain 
nine entries. The address of the first 
segment is contained in the DCBXARG field 
of the DCB, and each succeeding segment is 


chained to the one preceding it. The 
read-exclusive list is an intra-task list 
of device addresses of blocks (i.e., 


capacity records and data blocks) that are 
requested for the performance of the cur- 
rent task. 


There are two situations in which a 
block is to be read under exclusive con- 


trol. 
e A self-format ‘write-add' request is 
encountered. (See the section 


"Self-Format Channel Programs.") 


e A READ macro instruction that requests 
exclusive control is encountered. 


When either of these situations occurs, 
module IGGO019LG determines if the device 
address of the appropriate block is on the 
read-exclusive list. The appropriate block 
is the track capacity record in the case of 
a "write-add‘' request; in the case of a 
read-exclusive request, it is the block to 
be read. If the block address is on the 
list, the IOB for the request is placed on 
a queue called the unposted queue. This is 
an intra-task queue of IOBs representing 
requests for blocks whose addresses are 
currently on the read-exclusive list and 
are associated with the current task. The 
data control block contains the addresses 
of the first and the last IOBs on this 
queue, and each intermediate entry is 
chained to the one preceding it. Control 
is then given to the routine from which 
module IGG019LG was entered. 

If the block address is not on the 
it signifies that this 
is the first request for the record for the 
current task. The IOB contains the block 
address. The UCB pointer and the CCHHR 
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bytes of the device address of the block 
are put on the read-exclusive list. Since 
the same block may be required in the 
performance of another concurrent task, it 
is necessary to provide protection against 
unwanted changes to the block. Therefore, 
the exclusive control module causes the 
block to be placed on an inter-task queue 
by issuing an ENQ macro instruction for the 
block. (Before an entry can be removed 
from this queue, a DEQ macro instruction 
Must be issued for the entry by a routine 
associated with the task for which the 
entry had been enqueued. Since a block on 
this inter-task queue cannot be used in the 
" performance of one task until it is disas- 
sociated from another task, a waiting per- 
iod of indeterminate length may result.) 
Module IGG019LG then issues an EXCP macro 
instructions for the re-reading of the 
block that has just been enqueued. Control 
is then given to the ASI routine which, in 
turn, gives control to the supervisor. 


Note: For systems operating under the 
primary control program, there is no need 
for an inter-task queue. Therefore, when 
either the enqueue routine or the dequeue 
routine is given control, the routine 
returns control directly to the routine 
that had invoked it (i.e., the effect is 
the same as a no-operation). The Supervi- 
sor and Data Management publications con- 
tain further information regarding the use 
of the ENQ and DEQ macro instructions. 


In searching the read-exclusive list for 
either an address equal to the address of 
the block to be read or, having found that 
the block address is not on the list, a 
place on the list in which to place the 
block address, it may be necessary to scan 


through several segments of the read- 
exclusive list. A new segment is obtained 
if the second part of the search does not 


locate a place in which to place the block 


address. 


Releasing Blocks Under Exclusive Control 


Blocks that have been read under 
exclusive control may be released from 
exclusive control either by use of a WRITE 
macro instruction that specifies the exclu- 
sive control feature or by use of a RELEX 
macro instruction. The RELEX macro 
instruction is used for blocks that have 
not been updated or modified (i.e., their 
data fields remain unchanged). 


RELEASE BY WRITING: When a request (called 
a write-exclusive request) to write a block 
that has been previously read under exclu- 
Sive control is encountered, the read- 
exclusive list is scanned to locate the 
block's address. When the address is 
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RELEASE BY  RELEX: 


found, the unposted queue is searched for 
other requests (associated with the current 
task) that may have been issued for the 
same block. 


If a write-exclusive request is given to 
release a block from exclusive control and 
the block had not been read under exclusive 
control, the write request is invalid. 
Module IGG019LG sets an exception code in 
the IOBDSTAT field of the IOB so that the 
user may identify the error. Control is 
then given to the ASI routine to free the 
IOB and post the request as complete. 


If the unposted queue does not contain 
IOBs for other intra-task requests for the 
block, module IGG019LG clears the block's 
address from the read-exclusive list. This 
permits another entry to be made to the 
list at that space. To free the block for 
another task, the exclusive control module 
then issues a DEQ macro instruction for the 
block. Module IGG019LG then returns 
control to the supervisor. 


If the search of the unposted queue 
indicates the presence of other requests 
for the block that is being written out, it 
is necessary that these other requests be 
provided with the most current version of 
the data portion of the block. Therefore, 
before the current write-exclusive request 
is posted as complete, the exclusive con- 
trol module moves the data portion of the 
current block into the input data area of 
each “duplicate" request on the queue. 
Control then passes to the ASI routine so 
that the first of these “duplicate” 
requests may be posted as complete and its 
IOB made available. The ASI routine then 
gives control back to the exclusive control 
module and processing continues as if the 
unposted queue did not contain any read- 
exclusive requests for the block. 


When a RELEX macro 
instruction is given to release a block 
that was read under exclusive control, it 
is assumed that the data portion of the 


block has not been changed. Therefore, 
data is not moved into input areas of other 
"duplicate" requests. The procedures 


performed by the exclusive control module 
are otherwise similar to those performed in 
the case of a write request for blocks read 
exclusively. 


The RELEX module, IGC0005C, receives 
control when a RELEX macro instruction is 
encountered. After initialization, deter- 
mination of the type of addressing that has 
been specified, and conversion of a block 
address to an actual address if it is not 
already in that form, module IGC0O005SC gives 
control to the exclusive control module. 
If the block specified for release from 
exclusive control is not found by searching 


the addresses on the read-exclusive list, 
an error condition is indicated; the pro- 
grammer has requested the release of a 
block that was not under exclusive control. 
The exclusive control module sets an error 


code in register 15 and gives control to 
Table 6. 


| |Block Address 
|Macro instruction jAlready on 


-------------------- }-------------------+ 
j1. READ | Yes | 
| (Exclusive) | | 
}-------------—----- }------------------- + 
|2. READ | No | 
| (Exclusive) | | 
| | | 
| | | 
i i | 
}-------------------- }------------------- + 
|3. WRITE | No | 
| (Exclusive) | | 
}-------------------- }------------------- + 
|4. WRITE | Yes | 
| (Exclusive) | | 
| l { 
i | | 
{ 1 | 
l l | 
l I | 
PSSeSenen sora 1 mien oa ai rc aa + 
{5. WRITE | Yes | 
| (Exclusive) | | 
i | | 
| | | 
l | | 
Sa RAT Hao ERE 5 ea ar a + 
[6. RELEX | No | 
l i | 
p-------------------- }--------=---------- + 
}7. RELEX | Yes | 
| | | 
| | | 
| | | 
feSS=SSS- eee sss | Sanaa kaa atone GLa + 
}8.  RELEX | Yes | 
| | 1 
| | | 
| | | 
bese eee SIs a 4 


DYNAMIC BUFFERING (MODULE IGG019LE) 


The handling of all buffer requirements 
for BDAM requests is done by module 
IGGO19LE if the dynamic buffering feature 
is specified. These requirements include: 
obtaining and assigning buffers into which 
data may be read; placing buffer requests 
on a queue if there are no available 
buffers; and releasing buffers for other 


the RELEX module. The RELEX module gives 
control back to the processing program. 


Table 6 summarizes the exclusive control 
module's main functions as they have been 
described in the preceding paragraphs. 


Functions of the Exclusive Control Module for Specified Conditions 


a ama i aa daa Se ragabias neincorins anil aaa as crane 
jOther IOBs for 
{Same Block on | 


|That Requests Action|Read-Exclusive List|Unposted Queue| 


== |Place request's IOB on unposted | 
|queue. Go to supervisor. | 


re $--------------=----------------4 


= {Add block's address to _ read-| 
jJexclusive list. Enqueue block| 
Jon inter-task queue. Schedule| 


jthe block for reading. Go tof 

| supervisor | 
—---------- }------------—--------------—---4 
== jError exit to ASI. | 

l | 
----------- }----~----~--—-----------------+] 
Yes [Remove read request from queue. | 


|Move data into all read request] 
| areas. Go to ASI routine to| 
| post first read request on| 
|queue and free its IOB. Go tof 
{ASI routine to post write| 
jrequest and free its IOB. _. | 
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No |Go to ASI routine to post write] 
|request and free the IOB. 
| Remove entry from read- 


Jexclusive list and from 


| 
inter- | 
jtask queue. | 


Go to supervisor. 


=< jReturn to RELEX routine with| 
jerror code. | 


---~----—-- $o--------- =~ === 
Yes {Remove read request from queue. | 
|Go to ASI routine to post read| 

| request and free the IOB.| 

|Return to RELEX routine. | 

a aan renennye eee 4{---—..-_____-~- +--+ ---------- 
No | Remove block from read- | 
Jexclusive list and from inter-| 

Jtask queue. Return to RELEX| 

j routine. | 
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uses either after a request has_ been 
completed or when the FREEDBUF macro 
instruction is used. 


Buffer Assignment 


As each request to read data is about to 
be executed, the start I/0 appendage 
module, IGG019KS, checks the IOBDTYPE field 
of the IOB to see if there is a requirement 
for a buffer to be assigned to the request. 
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If a buffer is required, a check is made to 
determine if a buffer has already been 
assigned to _ the request. Note that 
requests for dynamic buffer assignment may 
occur whether or not the exclusive control 
option is specified for read requests. If 
a request has an assigned buffer, the 
channel program may be initiated. Ifa 
buffer is needed, the start I/O module 
gives control to the dynamic buffer module. 


The dynamic buffer module ascertains 
whether all buffers in the buffer pool (the 
buffer pool was established and initialized 
by the open executor program) for the data 
set have been allocated to other requests 
or if one is available. If a buffer is 
available for the current request, it is 
assigned to the request, and the entries in 
the buffer pool are updated to reflect the 
effective removal of the buffer. The asso- 
ciated channel program is completed by 
placing in it the buffer addresses into 
which information is to be read, and then 
the channel program is ready for execution. 


If no buffers are available to satisfy a 
buffer request, the IOB is placed on a 
queue of requests waiting for buffer 
assignment. The elements of this queue are 
chained to each other through addresses 
given in the IOB. The addresses of both 
the first and the last request on the queue 
are given in the buffer control block. As 
buffers subsequently become available, they 
are allocated to the requests on the queue. 
As each request is added to the queue, it 
becomes the last request of the queue. 
When a buffer becomes available, it is 
allocated to the request currently at the 
top of the queue (i.e., the first request 
on the queue), and that request is removed 
from the queue. 


Releasing Buffers 


When a request using a dynamically- 
assigned buffer has been completed (either 
successfully or unsuccessfully), the buffer 
that has been assigned to the request may 
be made available for other requests. This 


32 


of available buffers. 


can happen in one of two ways: control may 
be given to the dynamic buffer routine 
either by the ASI routine or as the result 
of a FREEDBUF macro instruction being 
encountered in the processing program. 
Note that a buffer assigned to a read 
request for a block that is not to be 
updated will be released when the request 
is completed only if the FREEDBUF macro 
instruction is issued for that request's 
buffer. For a block that is to be updated, 
a buffer is retained until freed by a 
corresponding write request that specifies 
dynamic buffering. 


After the ASI routine receives control 
at the completion of a write request, it 
gives control to the dynamic buffer module 
if dynamic buffering is being used. If a 
dynamic buffer routine finds an IOB on the 
buffer queue waiting for a buffer, it 
assigns the buffer from the just-completed 
request to the top request of the queue. 
The buffer queue is updated by moving each 
request up one position on the queue. The 
channel program for the selected request is 
then completed (as described in the section 
"Buffer Assignment"), and the dynamic buf- 
fer module issues an EXCP request to exe- 
cute the channel program. 


If there are no entries on the buffer 
queue waiting for buffers, the buffer from 
the completed request is placed on the list 
The buffer control 
block and its entries are then updated as 
required to include the added buffer. The 
dynamic buffer module then gives’ control 
back to the ASI routine. 


When a FREEDBUF macro instruction is 
encountered in the processing program, the 
supervisor gives control to the dynamic 
buffer module. A routine in this module 
then checks for other queued requests and 
assigns the freed buffer or makes it avail- 
able for future buffer requests as dis- 
cussed for the entrance from the ASI rou- 
tine. The dynamic buffer module then gives 
control back to the supervisor. 


e * 


in the DECB, the check routine 


CHECK MODULE (MODULE IGG019LI) 


To ensure that*ta given read or write 
request is completed before a certain point 
in the associated processing program, eith- 
er a CHECK macro instruction or a WAIT 
macro instruction must be coded following 
the request in the processing program. The 
BDAM check module, IGG019LI, is used when 
the CHECK macro instruction has been speci- 
fied and the DCB macro instruction for the 
data set includes the check specification. 
The address of a user's synchronous error 
recovery (SYNAD) routine should be given in 
the same DCB macro instruction that con- 
tains the check specification. 


When the check module receives control, 
it establishes a wait condition if the 
associated request has not been posted as 
complete. If the request is complete at 
this point or is subsequently completed 
while the processing program is in the 
‘wait’ state, and if no errors have been 
indicated in the DECB, the I0B for the 
request is released to the IOB pool, and 
control is given to the processing program. 
(When the DCB macro instruction includes 
the check specification, the CHECK macro 
instruction must be used to effect the wait 
condition; if the WAIT macro instruction is 
used, the I0B for the request is not 
released.) 


After a request is posted as _ complete 
and if error indications have been placed 
identifies 
both the type of request and the types of 
errors listed. The error types are placed 


in a register and control is given toa 
SYNAD routine if one is present. The 
publication IBM System/360 Operating Sys- 


tem: Supervisor and Data Management  Macro- 
Instructions, indicates the contents of 


registers when the BDAM check module gives 
control to a SYNAD routine. The absence of 
a SYNAD routine causes BDAM to terminate 
the processing program. 


THE BDAM CLOSE EXECUTOR PROGRAM 
(MODULE IGG0203A) 


The BDAM close executor program consists 
of module IGG0203A. This module is given 
control during the closing of a DCB that 
specifies BDAM. (See Figure 8.) When the 


CLOSE macro instruction is encountered in a 
processing program, the expansion of the 
macro instruction causes program control to 
be given to the data management’ close 
routine. This routine uses the BDAM close 
module as a subroutine. 


The main purpose of the BDAM close 
executor program is to release to the 
system all BDAM-acquired storage areas that 
have been associated with the DCB to which 
the CLOSE macro instruction refers. This 
is done in from two to four steps depending 
on the type of requests used in the 
application. 


The first step consists of removing from 
the I/O supervisor scheduled queue of 
requests any requests that have been sche- 
duled but whose operations (i.e., channel 
programs) have not yet completed. The 
purge routine of the I/O supervisor accom- 
plishes this removal. The BDAM close exe- 
cutor program then releases the main stor- 
age area assigned to the IOBs for these 
requests. These requests are chained 
together, beginning with an address placed 
in the DEB by the purge routine. 


The second step is the releasing of main 
storage areas assigned to available IOBs on 
the list of I0OBs. The IOB list also 


includes the I0Bs' that are on either the 
I/O supervisor scheduled queue or a buffer 
queue. Therefore, only storage for IOBs 
not currently being used is released at 


this time. 


The third step is the releasing of 
storage that has been allotted to any IOBs 
remaining on the unposted queue. These 
IOBS were placed on the queue by the 
exclusive control module. 


As a fourth step, the storage that has 
been allotted to IOBs remaining on the 
buffer queue is released. (The IOBs on the 
buffer queue are those waiting for buffers 
to be made available to’ them.) The main 
storage areas that have been obtained both 
for the buffer control block and for buf- 
fers to be assigned dynamically are also 
released in this fourth step. 


In addition to releasing the storage 
areas assigned to I0OBs, the BDAM close 
executor program clears from the DCB all 
fields that the BDAM program has built up 
for, and that specifically refer to, the 
current use of the DCB to which the CLOSE 
macro instruction refers. 
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IOB 


The IOB is constructed by the foundation 
module base component. The fields of the 
IOB are constructed dynamically as a pro- 
cessing program is executed. The storage 
area used for the IOB is obtained either 
from a pool of available IOBs for which 
storage has been previously obtained or by 
use of the getmain routine. If the area is 
taken from a pool of IOBs, that area is 
made unavailable to the pool during the 
life of the associated request. 


When a request is completed, the asso- 
ciated IOB is either replaced in the pool 
or assigned to the pool for the first time, 
depending on how the IOB was obtained for 
the request. If the IOB was obtained from 
the pool, it is returned to its former 
position in the pool by setting the availa- 
bility byte in the IOB to '0'. If the IOB 
was obtained by the getmain routine, it is 
placed in the pool according to its size, 
the ‘next I0B* pointers are updated as 
necessary, and the availability byte is set 
LO TO" 5 


All storage areas assigned to IOBs are 
released to the control system by the 
freemain routine at the time the DCB is 
closed. 


Note: If the first usage of an IOB storage 
area occurs with an invalid request, then 


APPENDIX A: CONTROL BLOCKS FOR BDAM 


the area is returned to the system by using 
the freemain routine rather than being 
placed on the pool when the request com- 
pletes. 


Various BDAM routines use some of the 
fields in the IOB as temporary work areas 
until such time as these fields are filled 
in with information as described in Table 
7. 


There are three main sections to the IOB 
as used by the basic direct access method. 
(See Figure 9.) The first part is a 
standard 40-byte section and is described 


in the publication IBM System/360 Operating 


System: System Control Blocks, Form 
C28-6628. BDAM refers to this part, for 


example, to determine the status of a 
completed channel program and to _ locate 
addresses of storage areas to be used as 
work areas. 


The second part of the IOB is a 40-byte 
section that contains information needed by 
BDAM to process the related request. The 
11 fields in this part are described in 
Table 7. 


The third part contains the channel 
program that is constructed for the input 
or output request. The channel command 
words are placed in this part of the IOB as 
they are formed. 
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+0 +1 +2 +3 +4 +5 +6 +7 
Se a ene a se ae sam ee eee i a aie in aes se ae et meme es oe ce ea ae ee ae ane ae A 
+0 | Flag 1 | Flag 2 | Sense | IOBECBPT | | 
f---------4--------4_---------------- 41-—--—~~~---—-----------------~------ 1 | 
+8 | Channel Status Word | | 
}--------- y--~--~--—----------------- Yorn nnn nnn nnn === 1 
+16 | | Channel-Program | IOBDCBPT | Standard 
| | Starting Address | | IOB 
}--------- 4---~-~----~--------------- $+----------------- q----------------- 1 | 
+24 | IOBRESTR | IOBINCAM | IOBERRCT | | 
}----~-----------------—------------ Bannan nnn nn Bonn 1 | 
+32 | IOBSEEK | | 
| (M B B Cc Cc H H R) | Vv 
apace eae as ad a et = 
+40 | IOBDBYTR { IOBDIOBS | IOBDAVLI | IOBDPLAD | A 
woman en entra aa fen nnn fh nnn nnn neem | 
+48 | LOBDTYPE | IOBDSTAT | IOBDCPND | | » 
pron nnnnnn n= --——— ERE fen nnn nn en enn nnn 1 | : 
+56 | IOBDBYTN | i IOBDQPTR | | 
[------------------ Bamana nnn nnn Bn i | 
+64 | IOBUPLIM | BDAM 
---------------------------------------------------------—-—--------------- 4 Extension 
+72 | IOBDNRCF | to 
[~~---~---~~-~-~~~+~~ +--+ +--+ + + + + 5 + 5 { IOB 
+80 | CHANNEL | | 
. | PROGRAM | | 
- | | | 
| ; | | 
- | (Length varies according to channel program. Refer to Appendix C.) | | 
- | | | 
ai | | 
. USS 2 eess ooo ee Sata ee eee ee eee ee 5 Vv 


Figure 9. 


Fields of the IOB for BDAM 


Table 7. Fields, Field Size, and Field Contents of the IOB for BDAM (Part 1 of 4) 


ee ee ee ee 


IOBDIOBS 


IOBDAVLI 


Field Size 
(in bytes) 


Field Contents and Comments 


Ge a ns ih ce ce cs cc ce lc as a i a wma se ad Sh Sa eo es es a 4 


Number of unused bytes remaining on a track on which a new 
variable-length block or a new undefined-length block is to 
be written. This value is initially placed in IOBDBYTR when 
the channel program reads the capacity record. Subsequent 
updating of the IOBDBYTR field is done by the self-format 
module, IGG0O19KM. The channel program later updates the 
capacity record before the input/output operation is complet- 
ed. 


Overall size of the I0B, specified in bytes. The base 
component of the foundation module places this value in 
IOBDIOBS after the main storage area for an IOB has_ been 
obtained. 


Indication of the availability of the IOB. When the IOB is 
taken from the pool of available IOBs, the value of IOBDAVLI 
is set to a hexadecimal FF to indicate that the IOB is being 
used (i.e., unavailable). This is done by the base component 
of the foundation module. When an input/output operation is 
posted as complete, and an I0OB is either returned to or 
placed on the pool of available IOBs, the value of the 
IOBDAVLI field is set to zero. Depending on the cause of the 
completion of the I/O operation, the zero value is set by 
either the asynchronous interrupt component or the invalid 
request routine of the foundation module. 
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Table 7. Fields, Field Size, and Field Contents of the IOB for BDAM (Part 2 of 4) 


q Cor 2 a Re eaaaat ie nae ae ee ee ty a Pet ae mT Ce ee ea 1 
4 | Field Size | | 
q | Field | (in bytes) | Field Contents and Comments | 
}---------- }------------ aE SEC> 7 SS RUE PLE CTR a Lag ERG a 1 
4 | IOBDPLAD | 3 | Address of the next IOB area in the pool of IOBs attached to | 
1 i | {| the current DCB. If there are no more IOBs on the pool, the | 
q | | | value of this field is zero. Each IOB on the pool became a | 
q | | | member of the pool after the first usage of the IOB. When a | 
q | | | new IOB is added to the pool, the IOBDPLAD field of the | 
4 | | | preceding IOB is updated. | 
4 | | | 
4 | IOBDTYPE | 2 | Indication of the request type and indication of any options | 
: | | | specified in the DECB related to the request. The contents | 
7 | | | of the DECTYPE field (see DECB block) are placed in the | 
‘ | | | IOBDTYPE field when the IOB is initialized. Significant bits | 
q | | | of the IOBDTYPE field and their interpretations for BDAM are | 
: | | | as follows. (When the bit is set to '1', the interpretation | 
1 | | | is in effect. When the bit is set to '0', the interpretation | 
| | | | is not in effect.) | 
q | | | 
‘ | | | First Byte: | 
1 | | | 
1 | | | Bit 0: Indicates verification of written block is desired. 
4 | | {| Bit 1: Indicates track overflow (i.e., overflow blocks are | 
| | | | being used). (Refer to the publication IBM | 
| | | | System/360 Operating System: Sequential Access Meth- | 
q | | | ods, Program Logic Manual.) | 
: | | | Bit 2: Indicates extended search is desired. | 
j | | {| Bit 3: Indicates feedback of block address is desired. | 
4 | | | Bit 4: Indicates actual block addressing is being used. | 
q | | | Bit 5: Indicates dynamic buffering is being used. | 
Tog. | | | Bit 6: Indicates exclusive control is being used. | 
3 Y ! | Bit 7: Indicates relative block addressing is being used. | 
| 
: | | | | 
: | | | Note: If both bit four and bit seven are 0, the interpreta- | 
4 ! | tion is that relative track addressing is heing used. | 
; | | | | 
q | I | Second Byte: | 
| | | 
| | | Bit 0: Indicates that an 'S' has been specified in the key | 
| | | address operand of the READ or WRITE macro instruc- | 
| | | tion. For dynamic buffering, a buffer is to be | 
: | | | allocated for a read request, and the key part of a | 
¥ | | | buffer is to be freed after a write request. | 
| | | Bit 1: Indicates that an ‘'S* has been specified in the | 
| | | length operand of the READ or WRITE macro instruc- | 
| | | tion. The setting of this bit is ignored (i.e., not | 
‘ | | | tested) when writing variable-length blocks since the | 
| | | block length is given in the first two bytes of the | 
| | | data field. | 
| | | Bit 2: Reserved for future use. | 
| | | Bit 3: Reserved for future use. | 
| | | Bit 4: Indicates a read request. (A 'O* indicates a write | 
| | | request.) | 
| | | Bit 5: Indicates the search argument is the block key. (A | 
| | | 0° indicates the search argument is the block ID.) | 
| | | Bit 6: Indicates a write request to add a new block. | 
| | | Bit 7: Reserved for future use. | 
| | | 
{| IOBDSTAT | 2 | Indication of status of the related request. Significant | 
| | | bits of the IOBDSTAT field and their interpretations for BDAM | 
| | | are as follows. (When the bit is set to '1', the interpreta- | 
| | | tion is in effect. When the bit is set to ‘'O', the | 
| | | interpretation is not in effect.) | 
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Table 7. Fields, Field Size, 


Field Size 
(in bytes) 


IOBDSTAT 


(Cont. ) Bit 


Bit 


Bit 
Bit 


Bit 


Bit 


Bit 


Bit 


IOBDSTAT 


Bit 
Bit 
Bit 


Bit 
Bit 


Bit 
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and Field Contents of the IOB for BDAM (Part 3 of 4) 


0: 


1: 


2: 
3: 


Ws 


5: 


63 


7: 


0: 


Field Contents and Comments 


Indicates an abnormal completion of the request. See 
second byte for details. 

On extended search, this indicates that the ASI 
routine is to issue the EXCP macro instruction after 
the end-of-extent appendage has determined that the 
next extent is on a new volume. The end-of-extent 
appendage cannot issue an EXCP macro instruction in 
this case. 

Reserved for future use. 

On extended search, indicates to relative block 
conversion routine that the second pass of a two-pass 
conversion routine has been completed. 

Note: The first pass of the routine converts’ the 
Starting address for a track search, and the second 
pass converts the address for the search limit. The 
bit is set to ‘1' when the second pass begins. This 
bit is also set by the self-format module after the 
module has calculated the number of bytes required in 
order to write a block ona track. Then, if 


additional tracks must be examined for space, the- 


calculation of bytes required is bypassed. 

Indicates that the read-exclusive request related to 
this IOB has been placed on an inter-task queue by 
the exclusive control module. 

Indicates that a buffer has been assigned to this 
IOB. 

Indicates that a given block (to be written) can fit 
on the track associated with the capacity record that 
has just been read into storage. Module IGG019KM 
sets this indicator. 

Indicates to dynamic buffer module that it was 
entered from, and is to return control to, the start 
I/O appendage module. 


Second Byte: This byte contains indications of an abnormal 
completion of a request. When the request is posted as 
complete, these indications are placed in byte 1 (the second 
byte) of the DECSDECB field of the DECB. 


Indicates that the requested block was not found on 
the indicated track. 

Indicates that the length of the block was incorrect. 
(Refer to the section "Channel End Appendage 
Module.") 

Indicates that no space was found in which to write a 
new block. 

Reserved for future use. 

Indicates that a read operation (either to bring data 
into main storage or as a verification of written 
data) has resulted in a data check error that has not 
been corrected by the standard IOS error retry proce- 
dure. (Refer to the section "Verification Program.") 
Indicates that the request has been completed but 
that the block the user has requested to be read or 
written is an end-of-data set record (indicated as 
having a data field length of zero). (Refer to _ the 
section "Channel End Appendage Module.") 

Indicates an error that cannot be attributed to any 
other cause as indicated by the bits in this byte. 
Indicates no match has been found on the _ read- 
exclusive list. 


re a ee see cee nee core ce el a ce ree came me ee cee cee cate mr te se  <e  e  c ce e c  se m c  c e  s  c ae  e e ee e e c re e e  e a  e e 


| 
SO a a a a a le mm j 
First Byte: 


ee a a a NP ey a a eS CS a 


Table 7. Fields, 

r T T 
| {| Field Size | 
| Field {| (in bytes) | 
(----——--=- 1 casa Sa ears RLS + 
| IOBDCPND | 4 | 
| | | 
| | | 
| | | 
| | | 
| | | 
i i | 
| | | 
| | | 
| | | 
| I | 
| | | 
| | | 
| IOBDBYTN | 4 | 
| | | 
| | | 
| | | 
| | | 
| IOBDQPTR | 4 | 
| { | 
| | | 
| | | 
| IOBUPLIM | 8 | 
l { | 
| | | 
| i | 
| | | 
| | I 
| IOBDNRCF | 8 | 
| | | 
| | | 
L 


eee eee ee ha eo eh a on a ee ee 


Field Size, and Field Contents of the IOB for BDAM (Part 4 of 4) 


Field Contents and Comments 


The main storage address of the expected end of the related 
channel program if the program goes to a normal completion. 
This address is placed in IOBDCPND by the base component of 
the foundation module. 


At the completion of a request, the I/0 supervisor routine 
places an address in the channel status word. This address 
is equal to the address of the last channel command word 
executed plus eight bytes. 


A normal completion is indicated if the two addresses are 
equal and there have been no error indications. 


Indication of the required number of bytes to contain a new 
block. This value is calculated by the self-format module 
after control has been given to this module by the ASI 
routine. 


Address of the next IOB on the dynamic buffer queue of IOBs. 
This value is determined either by the dynamic buffer 
routine. 


Address to be used as_ the location in which to begin the 
search for the start of a track on which the indicated block 
is contained or is to be written. On extended search, this 
field indicates the address of the first track following the 
last track to be searched. 


The count field developed by the self-format module when a 
new block of either variable-length records or records of 
undefined length is to be added to a track. 


See cwe ote eee eee Se See See a ee eee eee 4 
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DECB 


The DECB' results from the expansion of 


either a READ or a WRITE macro instruction. tents of the fields is given in Table 
The contents of the fields of the DECB as with reference to Figure 10. 
+0 +1 +2 +3 +4 +5 +6 +7 
POs oF po eA Reo Oe ae ee ee ee ee Woes ee Se ee 
+0 | DECSDECB | DECTYPE | DECLNGTH 
}---+-~~+---~~--~--~+--------- --- ------------ 4{-------------------- 5 Sere ice ee ae ee ee 
+8 | DECDCBAD | DECAREA 
}----------------------------------------- $-——-——-—----—- === <== = = 
+16 | DECIOBPT | DECKYADR 
}----------------~--~---~----------------- faa = nn nnn nnn nnn nnn nnn nnn 
+24 | DECRECPT | 
a ee el eh ae J 
Figure 10. Fields of the DECB for BDAM 
Table 8. Fields, Field Size, and Field Contents of the DECB for BDAM 
SAE any enero qo nnn nn on en nn ne 
| Field | Field Size | Field Contents 
| | (in bytes) | 
}---------- }-----—----- }---------------------------------—~------- === == 2-252 -=--- 
| DECSDECB | 4 | Standard Event Control Block (ECB). (Refer to the IOBDSTAT 
| | | field of the IOB.) 
| | | 
| DECTYPE | 2 | Type of request operation. The contents of this field are 
| | | described in the discussion of the IOBDTYPE field. 
| | | 
| DECLNGTH | 2 | Length of data portion of the block being processed. 
| | | 
| DECDCBAD | 4 | Address of the DCB to which a request is related. 
| | | 
| DECAREA | 4 | Area into which the data portion of a block is to be written 
| | | or from which it is to be read. 
| | | 
| DECIOBPT | 4 | Address of the IOB associated with this DECB. 
i i | 
| DECKYADR | 4 | The contents of this field vary as the type of request to 
| | | which the DECB refers. 
| | | 
| | | Type of Request DECKYADR Contents 
| | | 
| | | Write by ID Address of the Key to be written. 
| | | 
| | | Write-Add Address of the Key to be written. 
| | | 
| | | Read by ID Address of the area into which the Key is to 
| | | be read. 
| { | 
| | | Read by Key Address of the Key to be used as a search 
| | | argument. 
| | | 
| | | Write by Key Address of the Key to be used as a_e search 
| | | argument. 
{ l | 
| | | Write-Add Key to be written to replace the dummy key. 
| | | (Format F) (Searching is done on the hexadecimal ‘FF‘ 
| | | of the dummy record.) 
| | | : 
| DECRECPT | 4 | Address of the blikref field. 
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they relate to BDAM are explained in the 


publication > 


IBM System/360 Operating 


System: Supervisor and Data Management 


Macro Instructions. 


A summary of the con- 
8, 


\& 


DEB 


The DEB is constructed during Phase 1 of 
the BDAM open executor program. The fields 
of the DEB that are specifically related to 
BDAM are the DEBAMLNG field, the DEBNMTRK 
field, and the fields of the relative 
extent areas. (See Figure 11.) A more 
complete description of the DEB is_ con- 
tained in the publication IBM System/360 


Operating System: System Control Blocks. 


one-byte field 
of main 


The DEBAMLNG field is a 
containing the number of words 


storage that contain the relative extent 
areas. 

The DEBNMTRK field is a two-byte field 
containing the number of tracks in the 
corresponding actual extent. 

The relative extent areas are formed 


only when relative block addressing has 


If track overflow has not been speci- 
fied, each relative extent area consists of 
a one-byte field that contains the number 
of blocks on a track (for the device used) 
and a three byte field that contains the 
number of blocks in the extent. This 
latter value is obtained by multiplying the 
number of tracks in the extent (given as 
the value in the last two bytes of the 
associated actual extent) by the number of 
blocks on a track. 


If track overflow has been specified, 
each relative extent area consists of only 
a three-byte “blocks per extent" field. 
The byte preceding each "blocks per extent" 
field is unused. In addition, two one-word 
fields constituting an overflow section are 
inserted between the last actual extent 
area and the first relative extent area. 
The values in these fields are based on the 


extent Parea for each actual extent area in Siz@ Of the period that is calculated by 
phase 3 of the BDAM open program. 
the DEB. 
+0 +1 +2 +3 +4 +5 +6 +7 
gen a ee re ee ee oe ee Oe ee Pie ee = er ee ee eS ed 
+0 | Basic | DEBAMLNG | | 
| Data t--——---~ 4 | 
| Extent | 
| Block 
--------  HaEEaIaDan ni neDgnTuDsipOubsDuaRada aR ER aD REREREREEEESSEERSOE PRR taleneneoeesaeienpeateteT - 
+32 | DEBVMOD| DEBUCBAD | DEBBINUM | DEBSTRCC | _A 
f-------- Ea ms nO : aRsesaane aaa a SEE pepe { | 
+40 | DEBSTRHH | DEBENDCC | DEBENDHH | DEBNMTRK | Actual 
------------------+--~-------------- 4----—-----——--—----- t--—--—-—~--------~- 4 Extents 
| [ | 
Ma a a a a a te Jj | 
e bd | 
e be | 
. . Vv 
CSS ne ee eee ee ee Ge er eee ee ee 1 = 
| Tracks per Period? | Blocks per Period | Overflow 
| | | Section 
f=-+==--= aa as alae Dig aa area 5 a A a i haa al { = 
| Blocks | Blocks | | A 
| per | per | | | 
| Trackt | Extent | | 
L..-----—— ban en nn nn nn nn 4t-—-------~--- - - --- -- --- - -- - ----- + 4+ Relative 
. - Extents 
d : | 
oe e Vv 
Re pe eee te oie ee eee oe Aa Aaa aia al See aS 1 ne 
| | | | | A 
baer ae a Lea aa Sa ee aoe eet ee J | 
es - | 
7 - Subroutine 
° . IDs 
a a ee oS a a a aa ee 7 | 
| | | | | | 
a ae ee eo I cn th cs a J Vv 


1See text. 


Figure 11. Fields of the DEB for BDAM 
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DCB 


the DCB is contained in the publication IBM 


System/360 Operating System: System Control 
Blocks. The fields of the DCB that are of 


The DCB (see Figure 12) contains infor- particular interest to programmers’ con- 
mation relating to the current use of a cerned with BDAM applications are indicated 


Table 9. Fields, Field Size, and Field Contents of the DCB for BDAM 


(oe re ee ee ee eee cee ee ee ee ee ee ee ee ee ge 


data set. A more complete description of in Table 9. 
+0 +1 +2 +3 +4 +5 +6 +7 
ee I Ee em ge a Ee ee eee ee Et ae age en eae 1 
+0 | | 
}-----~---------------------------------------------------- ------------------------- { 
+8 | 

 ueRbeumreinianian GS me ee pe ee PN a ee a Te a ee ee 
+16 | DCBKEYLE | DCBREL | 

}---------- Pew senelotiaea eames oles eS SaaS 4 

| 
+24 | Basic 

| 

| Data Control 

| 

| Block 

| 

| t----------------~------------- 1---------- [o-oo $$ == ---------- 
+48 | { DCBREAD or DCBWRITE | DCBOPTCD | DCBCHECK 

}-~-------- Pie se ete eee ee eas eee 4~—--------— PostSecret S oe 
+56 | DCBSYNAD | | DCBBLKSI 

a a fae ee eee ee 
+64 | | 

f eres GE SS A A ES Ce ee 4--------~-+--~-~-----+----—--~----—-- eo ow cee ow a ee we ee 
‘+72 | DCBIOBUQ | DCBUQND 

}----------7-----------—------------------ }----------y----~------------------------- 
+80 | i DCBLIMCT | | DCBXARG 

}----------1----------—--~------------- =~ }----------4-----------~------------------ 
+88 | DCBDRDX | DCBDFOR 

Sc aaa ST Lo aa a san aa a Pc 
+96 | DCBDFBK | DCBDYNB 

bo ee ee ee ee Ce ee ee Loci Soe eo Se ee SS ee Sees 
Figure 12. Fields of the DCB for BDAM 


SSS Si aa a A aa a RR en ka a ah ara 1 
{ Field | Field Size | Contents and Comments | 
{| (in bytes) | | 
~--------- }------------}------~----------------------------—--—-----——-----------------4 
DCBKEYLE | 1 | Length of Key field for each block in the data set. | 
| | | 

DCBREL | 3 | Number of relative tracks or blocks in the data set. This | 
| | number is placed in the DCBREL field by the BDAM open | 

| | executor phase 2 routine, and it can be used by the | 

| | processing program in the process of conversion of a relative | 

| | address. | 

| | | 

DCBREAD | | | 
or | 3 | Address of the BDAM Foundation module, IGG019KA. | 
DCBWRITE | | | 
| | | 

DCBOPTCD | 1 | Indication of options specified for the data set. Signifi- | 
| | cant bits of the DCBOPTCD field and their interpretations for | 

| | BDAM are as_ follows. (When the bit is set to '1', the | 

| | interpretation is in effect. When the bit is set to '0', the | 

| | interpretation is not in effect.) | 

pi iain RS ok ala a A ke et ae ee Se 
(Continued) 


46 


Table 9. Fields, Field Size, and Field Contents of the DCB for BDAM (Continued) 
» 

SS 5 ee ee ee ee a ed 
| Field | Field Size | Contents and Comments | 
| | (in bytes) | | 
actrees ema tensa sgo os eS te e  ee  e  e ee ee a 1 
| DCBOPTCD | | Bit 0: Write-validity-check option has been specified. | 
{| (Cont'd.)| | Bit 1: Reserved for future use. | 
| | | Bit 2: Extended search has been specified. | 
| | | Bit 3: Feedback has been specified. | 
| | | Bit 4: Actual addressing has been specified.1 | 
| | | Bit 5: Dynamic buffering has been specified. (This bit is | 
| | | set by BDAM.) | 
| | | Bit 6: Reserved for future use. | 
| | | Bit 7: Relative block addressing has been specified.? | 
{ | | | 
| | | +If neither actual addressing nor relative block addressing | 
| | | has been specified (i.e., if bits four and seven are both 0), | 
| | | relative track addressing is specified. | 
{ | | | 
| DCBCHECK | 3 | Address of the check module, IGGO19LI. | 
| | | | 
| DCBSYNAD | 3 | Address of user's SYNAD routine. | 
| | | | 
| DCBBLKSI | 2 | Maximum size of a record block in the data set. | 
| | | | 
| | 4 | Reserved for future use. | 
| | | | 
| | 4 | Reserved for future use. | 
| | | | 
| DCBIOBUQ | 4 | Address of the first IOB on the unposted queue. | 
| | | | 
| DCBUQND | 4 | Address of the last IOB on the unposted queue. | 
[ | | | 
| DCBLIMCT | 3 | Number of tracks (for relative track addressing) or number of | 
| | | biocks (for relative block addressing) to be searched when | 
i { | extended search option is specified. | 
| { | | 
| | 1 | Reserved for future use. | 
| | | | 
| DCBXARG | 3 | Address of the read-exclusive list. | 
| | | | 
| DCBDRDX | 4 | Address of the exclusive control module, IGG019LG. | 
| | | | 
| DCBDFOR | 4 | Address of the format channel program generating module that | 
| | | is required for the block format indicated in the DCB macro | 
| | | instruction. This address is placed in DCBDFOR by the BDAM | 
| | | open executor phase 2 routine. | 
| | | | 
| DCBDFBK | 4 | Address of the feedback module, IGG019KG. This address is | 
| | | used only for relative block feedback specification. | 
| | | | 
| DCBDYNB | 4 | Address of the dynamic buffer module, IGGO19LE. | 
bases eS 2 Geapen ioe Se aaa cae oe i a 4 


The initial value of each of the address 


fields in Table 9 is '00000001.‘ When the 
data set is opened, the value of each 
address field that corresponds to a 


required BDAM module is changed to the main 


storage address of the module; the values 


of address fields corresponding to modules 
that are not required remain at ‘'00000001'; 
and the values of the DCBIOBUQ and DCBUQND 
fields are set to ‘00000000. ° 
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BCB buffers is released by the BDAM close 
executor routine. Figure 13 depicts the 
fields of the BCB, and Table 10 describes 

The buffer control block (BCB) is built the field contents. 
if the dynamic buffering option has been 

specified. Phase 3 of the BDAM open execu- 


tor routines obtains contiguous main stor- +0 +1 +2 +3 +4 +5 +6 +7 
age for both the BCB and the required (roo non {roo 1 
number of buffers. The BCB is initialized +0 | BCBFROT | BCBFRQB | 
by the open executor phase 3 routine, but -}------------------ +------------------ 4 
subsequent entries are placed in the BCB by +8 | BCBNABFR | BCBTBFRS | 
the dynamic buffering module. The main L-~-~---—~~----—~-~~ 41——--—--—~———~———-—4 


storage area for both the BCB andthe Figure 13. Fields of the BCB for BDAM 


Table 10. Fields, Field Size, and Field Contents of the BCB for BDAM ; | 
SEL Oe EE ET Ee gE ene et ee eee en Ee RT Se ee ee ee ee 1 3 


Se ee foo 
| Field | Field Size | Field Contents and Comments | 4 
| | (in bytes) | | . ; 
ener : aioe Ts a ee a ee { a 
| BCBFROT | 4 {| Contains the address of the first IOB waiting to be assigned | 7 
| | | a buffer from the buffer queue. The dynamic buffer module | E 
| | {| inserts this address. | q 
 carce | | —— 
| BCBFRQB | 4 | Contains the address of the last IOB waiting to be assigned a | z 
| | | buffer from the buffer queue. The dynamic buffer module | a 
| | | inserts this address. | 3 
! | | | 
| BCBNABFR | 4 | Contains the address of the next buffer that is available for | 
| | | assignment to an IOB. Initially, the open executor phase 3 | E 
| | | module inserts this address. Subsequent addresses are | q 
| | | inserted by the dynamic buffer module. | 5 
| ! | | 
| BCBTBRS_ | 4 | Contains an indication of the total size of the buffer pool | q 
| | | and the buffer control block. The open executor phase 3 | . 
| | | module inserts this value. | 
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READ-EXCLUSIVE LIST SEGMENT required, the read-exclusive module, 
Y IGG019LG, requests the storage. The BDAM 
close executor routine releases the storage 
The read-exclusive list is composed of area(s) that may have been obtained for the 
one or more 80-byte segments of storage. read-exclusive list segments. 
Each segment contains identifying and 
chaining information and has Space for nine Figure 14 indicates the contents of the 
8-byte entries that identify the blocks for fields of a typical segment of the read- 
which exclusive control is required. Phase exclusive list. Figure 15 indicates the 
1 of the BDAM open executor routine contents of the fields of each of a 
requests storage for the initial 80-byte segment's nine entries representing members 
segment, and if additional segments are of the read-exclusive list. 


+0 +1 +2 +3 +4 +5 +6 +7 
anne ae tae Ce 
+0] Identifying Self-Pointer | Pointer to Next Segment if one Exists | 

| | 
ee ee ee ace e ORV, | 
| | 
+8 | First Entry on List (See below) | 
| | 
fan nnn nn nce ee en een { 


Space for Seven More Entries 


| ----------------------------------~-------------------------------------------------4 


| | 
+72| Last Entry in This Segment | 


Figure 14. Description of a Segment of the Read-Exclusive List 


+0 +1 +2 +3 +4 +5 +6 +7 
freee Dre es Cet fa a A ee ae ee 1 1 
0|Address of the UCB] Address (CCHHR) of the block placed on the | zero | 
|for the block | = exclusive list* | | 
eee ee Se 9 PE a ane Net ee peas ener ener ares 4 


1This is the address of the track capacity record (RO) in the case of write-add 
requests for variable length or undefined length blocks. 


Figure 15. Description of an Entry in the Read-Exclusive List 
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APPENDIX B: MODULE IDENTIFICATION AND USAGE 


In Table 11, the BDAM modules are listed performed, the subroutine returns program 
alphabetically according to their coding control to either the module listed at the 
(listing) names. Opposite each module head of the column on, in the case of 
coding name is the functional name of the module IGG018KQ, to the foundation module. 
module. 

In Table 13, options that may be speci- 

In Table 12, the module listed at the fied in the MACRF field, the OPTCD field, 
head of each column may use the module(s) and the RECFM field of a DCB macro instruc- 
listed underneath it as ae subroutine. tion are related to the BDAM modules that 
After the subroutine functions have been are required to fulfill the options. 


° Table 11. Coding and Functional Names of BDAM Modules 


Ra a rh re a ee ee et en ete Me ge ee ae 1 
| Coding Name Functional Name 


ee ee ee ee ee ee ee nS ee ee ET es SS ee eee SS ate es Ce ees ee eee onli aoe 


| 
° ------------------ fn rr rs en errr ae 
| IGGO019KA | Foundation Module 
| IGG019KC | Relative Track Conversion Module 
| IGGO19KE | Relative Block Conversion Module without Track Overflow 
| IGGO19KF | Relative Block Conversion Module with Track Overflow 
| IGG019KG | Relative Block Feedback Module without Track Overflow 
| IGG019KH | Relative Block Feedback Module with Track Overflow 
| IGG019KI | Channel Program Generating Module for Searching by Block Key 
| IGGO019KK | Channel Program Generating Module for Searching by Block ID 
| IGGO19KM | Channel Program Generating Module for writing New Blocks of 
| | Variable- or Undefined-Length Records 
| IGG019KO ] Channel Program Generating Module for writing New Blocks of 
YY | | Fixed-Length Records 
| IGGO19KQ | Channel Program Generating Module for Verification 
| IGG019KS | Start I/O Appendage Module 
| IGG019KU } Channel End Appendage Module 
| IGG019KW | Key Extended-Search Module 
| IGGO19KY | Self-Format Extended-Search Module 
| IGGO19LA | Pre-Format Extended-Search Module 
| IGGO019LC | End-of-Extent Appendage Module 
| IGG019LE | Dynamic Buffering Module 
| IGG019LG | Exclusive Control Module 
| IGGO19LI | Check Moduie 
| IGG0193A | Open Executor Phase 1 Module 
| IGG0193C | Open Executor Phase 2 Module 
. | IGG0193E | Open Executor Phase 3 Module 
* | IGGO203A | Close Executor Module 
bees ee eee a ch ee ee ee 4 


Table 12. Peto nea ae of Control pene BDAM Modules 


: 
| IGGO19KA] IGGO19KI] 1GG019KK{ 1GG019KM] IGG019KO} IGG019KS] 1GG019KW] 1GG019KY| IGG019KH| 
deat a ORE LATS | Sane RSC RSOIE A Ben ICG Stee | Leu ING REED (ae UENN: TUR EIIROR Giecl Gm CL RRO ATED IRIE EG Gee ER TIE 

| IGGO19KC| IGGO19KW| IGG019KQ| IGGO19KY| IGGO19LA| IGGO19LE| IGG019KQ|1IGGO19LC| IGGO19KF| 
| IGGO19KE| IGG019KQ| IGG019KQ| IGG019KQ| 
| IGGO19KF| IGG019LG | 
| IGG019KG] 
| 
| 
| 
| 
| 
| 
L 
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BDAM Modules Required to Satisfy DCB Macro Instruction Options 


Table 13. 
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APPENDIX C: CHANNEL PROGRAMS FOR BDAM 


The channel program for each request using BDAM is constructed by the appropriate 
module and placed in the IOB for that request. A channel program consists of a group of 
channel command words (CCWs), each word having the following format: 


alae ae earn Pe a ee ee ee es ee ee ee eed 
| Command Code | Address | Flags | 000 | (ignored) | Count | 
| (1 byte) | (3 bytes) | (5 bits) | (3 bits) | (1 byte) | . (2 bytes) | 
(ese esceeSoesS Me et ota Y Cee eee 5 eee pen see nae oe oa as ile ee ean PS J 
Note: The last 4 bytes are ignored by a K. Skip the transferring of data. 


Transfer-in-Channel (TIC) command word. 
S. Suppress incorrect length indica- 
tion. 
The entry in the ‘Address' field is one 
of the following: 
The entry in the ‘Count' field repre- 
e The main storage address of where data sents either the number of bytes of data 
is to be placed or found; this is fora that are to be transferred or the number of 
Read or a Write command word. bytes of data on which a search is to be 
made for comparison. 
e The location of the search argument; 
this is for a Search command word. 
The function or purpose of each command 
e The CCW to which a transfer is made; word is given in the comment following the 
this is for a Transfer-in-Channel com- ‘Count’ field. The channel command words 
mand word. are identified by the number to the left of 
the command code. : 
The entry (or entries) in the ‘Flags’ 


field have the following meanings: If track overflow has been specified, 
; the applicable form of the channel program 
C. Command chaining. will end with a CCW having NOP as the 


command code and ignoring the other fields. 
D. Data chaining between gaps of a The preceding CCW will also have the com- 
record. Mand chaining (C) flag bit set on. 
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[eas apna aaa Pam magmas | PSPS Fa Rana dake { 
| CCW ]Command Code | Address | Flags | count | Comments | 
j No. | | | l | | | 
f------ }------------------------- +--------------- }-----}~--+------}-------------------- { 
j 1. |Search ID Equal | TIOBSEEK + 3 | c¢ |000] 5 |Search for an | 
| | | | | | jequal CCHHR. | 
}------ }--~---------------------- $--------------- +-----}---}------ }+------------------- { 
{ 2. | TIC jccw 1 | | | {Transfer if unequal. | 
| | | | | | | 

}------ f---7-~--~---------------- }-----------—-- t-----}---+------ }------------~-~----- 
| 3.% |Read (or Write) Key-Data |Key Address? | D |000|Key {Read (or Write) | 
| | | | | |Length|Key portion. | 
}------ }------------------------- }--------------- $-----}---}------ }-------------------- { 
| 4. |Read (or Write) Data jArea Address? | jO00|jData [Read (or Write) | 
| | | | | |Length|Data portion. | 
}------ }~------------------------ }--------------- +-----}---}------ }-------~------------ 
| 5.3 *|Seek cylinder head | IOBDNRCF } Cc |O00| 6 |Seek back to track | 
| | (CCHH) | | | | |containing beginning | 
| | | | tf Jof block. | 
}------ {-----------------------— }--------------- }-----}---}------}----------------—--- 
| 6. |Search ID Equal | IOBSEEK + 3 | ¢  |ooo] 5 | Locate the block | 
| { | | | | | just updated. | 
}------ }------------------------- fo-——~--—-—--- == +----- }---}------}-------------------- { 
| 7. | TIC |CCW 5 | | | {Transfer if unequal. | 
| | | | f of | 

[------ }------------------------- +--------------- }-----}---}------}-------------------- 
{ 8. j|Read Key-Data | | S,K [000| 256 |Read to validity { 
| | | | | | omaha | 
beseees Bt ee ee boos Sees se eee a a Ae ee 4 
j+ccW 3 is omitted if either the field DCBKEYLE or the field Sect TION is zero. | 
{?2This address is obtained from the DECB. | 
|3ccWs 5-8 are included only if the field DCBOPTCD specifies the write-validity-check | 
| option. | 
j“This CCW is present only if track overflow has been specified. 1 
Be Oe ae ee a ee ee J 


54 


| Channel Program for Reading or Writing by Block Key (Type DK) | 


fs=a-5 | SR Len a  icios eee aa eatin 5 ea Scene | eR oe | 
| CCW |Command Code | Address |Flags| |Count |Comments | 
| No. | | | | | | | 
}------ +------------------------- }---------------- +----- ---+------ +-------------------- { 
{ 1. |Read Count | LOBDNRCF + 2 {| c,S |O00] 5 |Read CCHHR for | 
l | | | | | | feedback. | 
}------ }------------------------- +---------------- }-----}---}------}-------------------- { 
| 2. |Search Key Equal |Key Address+ |] C,S {000|Key |Search for an equal | 
| I | I i | Length| Key. 
}------ }------------------------- $------——-------- }-----}---}------}-------------------- 
{ 3. {TIC jccw 1 | | | |Transfer if unequal. | 
| | | | ; 4 | 
}------ }------------------------- }------—--------- $----- $---}------ }-------------------- 
| 4. {Read (or Write) Data jArea Address? | {O00|Data |Read (or Write) | 
| | | | | |Length|Data portion. | 
- }------ }------------------------- +---------------- +----- +---}------}---~---------------- 
| 5.2 3|Seek Cylinder head | IOBDNRF | c {OO00|] 6 |Seek back to track | 
| | (CCHH) | | | | {containing beginning | 
{ i { | | | Jof block. | 
. | | | | | | | | 
f------ tense nner nnn fo-n none +—---+---+--—-- }-------------------- { 
| 6. |Search Key Equal | Key Address+ | C,S |000|Key j|Locate the block | 
| | | | | |Length| just updated. | 
}------ $------------------------- {------------~--- +----- +---+------ +-------------------- { 
{| 7. | TIC jccw 5 j | | | Transfer if unequal. | 
| { | | lol | 
}-----~ $------------------------- ---+------------ $----- $---+------ }~------------------- 
| 8. {Read Data | | S,K |000] 256 |Read to validity | 
l { { | ; 4 | check. | 
------- ae a AS EE PPS ee Bee a ee yee caEonE\ ial ee eee che ee es eS | 
|*This address is obtained from the DECB. | 
|2ccWs 5-8 are included only if the field DCBOPTCD specifies the write-validity-check | 
| option. | 
{2This CCW is present only if track overflow has been specified. | 
ge wre se a ere Dott ne ceo ee ee Oa et Neem pony SA Se as WN Rte ne ET eS ES 4 
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| Channel Program for Writing a New Block of Fixed-Length Records (Type DA) | 


f=====> Rp ee ce Se oe ee re { 
| CCW [Command Code | Address |Flags| |Count |Comments | 
| No. | | | | | | | 
}------ }~------------------------ +------—---—---- $-----+---4------ }-------------------- 4 
| 1. |Read Count | IOBDNRCF + 2 { C,S JO00] 5 j|Read CCHHR for | 
| | | | | | | feedback. | 
}------ }------------------------- }---------------- }-----}---4------}-—----------------- { 
| 2. |Search Key Equal |Dummy Key {| C,S |000] 1 |Search for a | 
: : ! } i |dummy record. | 
{ 3. | TIC {CCW 1 | | | |Transfer if unequal. | 
| | | | | | | 

t------ }------------------------- }----~----------- }~----}---}------}-------------------- 
{ 4. |Read Data | TOBDNRCF + 6 | c,S {O00} 1 |Read dummy record's | 
! t : i ‘i i 1 eroacia (i.e., R) | 

5.4% Seek cylinder head IOBDNRCF Cc 000 6 |Seek back to track 
Y 

| | (CCHH) | | | | jcontaining beginning| 
| | | | | | Jof block. | 
}------ }~------------------------ $---~--~--------- +-----}---}--—--}-------------------- 
| 6. {|Search ID Equal | IOBDNRCF + 2 | cC Joo0o}f 5 |Search for the | 
; i : ‘ : jdummy record. | 
| 7. {TIC ;ccw 5 | | | (Transfer if unequal. | 
| | { | | | | 

}-—---- }--~---------------------- }-----------—---- $-----t---}------ }--------—----------- { 
| 8. [Write Key-Data |Key Address? { Cc |000|Key {Update the Key | 
: ; | : : | Length| portion. ; 
| 9. [Write Data jArea Address? | {000|jData |Update the Data | 
| { | | | | Length| portion. | 
}------ }~---------=-------------- +---------------- }-----}---}------}-------------------- 
J10.+ 3|Seek cylinder head | LOBDNRCF } C¢ |O00] 6 |Seek back to track | 
| | (CCHH) | | | | {containing beginning | 
i l | | | | [of block. | 
------ }-------------------------}-----------=--- =f -----f---f -----f---- === ------------ 
j11. |Search ID Equal | TOBDNRCF + 2 | ¢ |ooo] 5 | Locate the block | 
: i i : i ! j just written. ; 
j12. | TIC jccw 9 | | | jTransfer if unequal. | 
| | | | | | | | 
f-25=2= 5 Sa exgie cRiice GCIs ree nes ome : Nemiaed aac aoa eee a Tos 5 near: Gamaare arenas SRS acne re cies ct 4 
J13. jRead Key-Data | {| S,K |000j] 256 |Read to validity | 
| i i | | | | check. | 
f-=---— fs eee Re el ee Be a eee 1 eae f Uepeenel arnerer seer 5 Re ie epee — 


{+This CCW is present only if track overflow has been specified. | 
{?This address is obtained from the DECB. | 
|?cCWs 10-13 are included only if the field DCBOPTCD specifies the write-validity-check | 
| option. | 
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Cre ee ee gg ee rt ee eee eo ee 1 
| Channel Program for Writing a New Block of Variable-Length Records or Undefined- | 
| Length Records (Type DA) { 


I SS en = ea 
| CCW |Command Code | Address |Flags| {Count |Comments | 
J No. | | | | | ; 
} 1. |Search ID Equal | IOBSEEK + 3 { Cc |000| 5 |Search for track | 
| | | | i | | capacity record. | 
}------ $------------------------- }---------------- }----- +---}------}-------------------- 
| 2. | TIC {CCW 1 | | | {Transfer if unequal. | 
i | | | i | | |. 
}------ }--~---------------------- $---------------- 4-----}---}------ }-------------------- { 
| 3. |Read Data | IOBDNRCF {| S |{000| 7 |Read capacity | 
| | | | ] | jxrecord into IOB. | 
t------ }------------------------- fanaa anne $-----}-—}------ }-------------------- { 
| 4. |Search ID Equal | LOBUPLIM | ¢ |000| 5 |Locate track | 
| | | { | | |capacity record. | 
}------ }------------------------- }---------------- 4$----- }---}------}-------------------- 
| 5. | TIC jccw 4 | | | {Transfer if unequal. | 
I l | | | | | | 
}------} ------~---- ---- ------ == fn nf nn nn pnp nn fone nnn n= 
| 6. jWrite Data | IOBSEEK + 3 {| C,S |000| 7 |Update capacity | 
| | | | t | |xecord. | 
p------ }--------- ---------------- }---------------- }-----}---}------}-------------------- 
| 7. |Search ID Equal j|CcCcW 12 {| ¢ |000] 5 |Locate current last | 
| | | | | | | block on track. | 
}------ }~------------------------ $---------------- ----- }---}------}-------------------- { 
| 8. | TIC {CCW 7 | | | {Transfer if unequal. | 
| | | | | | | 

}------ {------------------------- tocenanoo-------- $-----}---}------ }------------~------- { 
| 9. {Write Count-Key-Data | LOBDNRCF { D jooo| 8 | | 
| | | [ | | | l 
}------ $------------=------------ | a +-----+---}------ { | 
{10.2 |Write Count-Key-Data {Key Address? {| D |000|Key | | 
| | | | | |Length|Write new block. | 
}------}-------------------------}------=---------}-----}---f------ | 
j11.* |Write Count-Key-Data {Area Address? | }O00|Data_ | | 
| | | | | |Length| | 
}------ }------------------------- +---------------- }--~--}---}---=--}--------------- ~---- 
J12.5 |Search ID Equal { IOBSEEK + 3 } Cc |000{ 5 |Locate new block. | 
i | | | | | | | 
}------ }~-~---------------------- $---------------- $----- }+---4------ +-------------------- : 
}13. | TIC jCcCcw 12 | | | |Transfer if unequal. | 
| { | [ | | | | 
f------ }~------------------------ }--------~------- $-----+---}------ }-------------------- : 
{i4. {Read Key-Data | {C,S,K|000}| 256 |Read to validity | 
| | | | | | | check the block. | 
f------ $------------------------- $-----------—--- ¢-----$=--}------}-------------------- 
{15. |Read RO | {| K |0O00] 16 jRead to validity | 
| | | | | | {check the capacity | 
i |: ( | l | | record. | 
}---~-- hs aes ee peat ee oes ce a Se ee 
{+The IOB area that initially contained CCW 1 has been overlaid with 5 bytes (the CCHHR | 
| part) of the capacity record that was read by CCW 3. | 
|2CcCW 10 is omitted if keys are not present in the block format. | 
|?This address is obgained from the DECB. | 
|“cCW 11 is omitted if Data Length is 0 (i.e., end-of-data-set mark). | 
| SccWs 12-15 are included only if the field DCBOPTCD specifies the write-validity-check | 
| option. | 
be oo a ee ea eee eae aaa eee ae eee ae eee e 4 
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[ee aq SS ee 5 eas By ay re eee { 

| CCW | command Word jaAddress |Flags| jcount {Comments | d 
J No. | | | | | | | 
[------ }------------------------- }---------------- $----- $---t------ }-------------------- { 

{ 1. |Search ID Equal | LOBSEEK + 3 } c  |joooj 5 |Search for an | 

| | | | 1 | [equal CCHHR. | 

[------ }------------------------- }$---------------- $----- }---+------ }-------------------- : 

| 2. {TIC jccw 1 | | | |Transfer if unequal. | 

| | | | | | | 
}------ }------------------------- }---------------- $-—---}---}------ }-------------------- { 

| 3. [Multiple Track Search {| IOBUPLIM + 3 { ¢c jooo] 5 {Stop search at | 

| {ID Equal | | | | jlimit. | 

[------ }------------------------- }------—--------- }-----}---}------}-------------------- { 

| 4. | TIC {CCW 6 | | | |Transfer if unequal. | 

| | | | | | | | 

}------ feoween noe nn ne funen naan --- === +--—--}---}--——-- frnna- meee enone == {1  - & 
eee | NOP | { s | j 1 |Search limit | . : 
| { | | | | | reached. | 

}------ }------------------------- }---------------- }----- ---+------ }-------------------- { 

| 6. |Search Key Equal |Key Address {| C,S |000|Key | | e 

l I | | | | Length} | 

[------ }+------------------------- }+~--------------- $----- $---}------ }-------------------- : 

| 7. {TIC jccw 3 | | | {Transfer if unequal. | 

| | | | | | | | 

}------ --------------- ~--------- $---------------- }+----- +---}------ }-------------------- { 

| 8. |Read Home Address+ | |C,S,K[OOO| 1 | | 

| i | | | | | | 

}------ }~------------------------- }---------------- }----- ---+------ }-------------------- 1 

| 9. |Read Count | IOBDNRCF + 2 {| c,S [O00] 5 {Read CCHHR for | 

| | | | | | | feedback. | 

}------ }~------------------------ fon---------—---- +----- $-——4------ }-~---—-------------- { 

,10. |Search Key Equal |Key Address? | Cc  |000|Key |Search for equal | @ 

| | | | | | Length | key. | 

}------ }-=------------------------ }---------------- -----t---}------ }-------------------- { 

j11. |TIC |ccw 9 | | | |Transfer if unequal. | 

| | | { | 4 | 

}------ }------------------------- }~--------------- }-----}---}------}-------------------- 

Ji2. {Read (or Write) Data |Area Address? | jOO00|Data |Read (or Write) data] 

| | | | | jLength]|portion of block. | 

}------ }----~-------------------- }--~------------- $----- }-~-}-----~}--------~----------- 

|13.3 “|Seek cylinder head | IOBDNRCF {| Cc |O00] 6 {Seek back to track | : 
i | (CCHH) | | | | |containing beginning | q 
| | | | | | Jof block. | 
}------ }------------------------- $---------------- $----- $---}----~-}-------------------- { 

{| 14. |Search Key Equal |Key Address? | C,S |000|Key | Locate the block | “ 

| | | | | {Length| just updated. | . 
}~----- $------------------------- }---------------- +—---- }---}------}-+~------------------ 

}15. | TIC JCccw 13 | | | |Transfer if unequal. | 

| | | | | | | ° 
------- }------------------------- }------~--------- +----- $--~}------}-------~------------ 

,16. |Read Data | | S,K |000| 256 |Read to validity | 

| | | | 1 ol Wereat | 

}------ 5 ee Po ep Ee Oe Pe a fee eps Berry ee ea Ee is ee eee ee 4 

|+ccWs 8-11 are included if feedback is requested. | 

j2This address is obtained from the DECB. - | 

|?This CCW is present only if track overflow has been specified. | 

|*cCWs 13-16 are included only if the field DCBOPTCD specifies the write-validity-check | 

| option. | 

Cie e io seteba eee Shae SOG eR a ae he ee J 
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q ' GO a es er aye pe nn Ce ne 1 
] & | Channel Program for Writing a New Block of Fixed-Length Records Using Extended Search | 
4 [=s--=- ii ae a Lae ee 1 Siena Yo ee ete ee ee ee { 
. | CCW {Command Code | Address |Flags| {Count |Comments | 
| No. | | | | | | | 
}------ }------- ------------------ }---------------- }-----}-~-}------}-------------------- { 
} 1. |Search ID Equal | LTOBSEEK + 3 |} Cc jfooo]| 5 |Search for track | 
q | | | | | | | capacity record. | 
| }------ }------------------------- $---------------- }-----}-—-}------}--------------- -----4 
1 } 2. |TIc |Cccw 1 | | | {Transfer if unequal. | 
}------ }------------------------- fenen—- = fan mnprmponnn nn fonnn nnnn nnn n= 
4 j 3. |Read Data | TOBDNRCF + 2 | C,S [O00] 5 |Read highest ID from| 
q | | | | | j {capacity record. | 
}------ }------------------------- -----------—---- $-----}-——}------ }----~--------------- { 
3 | 4. {Search ID Equal | TOBDNRCF + 2 } c¢ |000] 5 | | 
}------ }------------------------- }---------------- +----- $---}------ }~------------------- { 
q . {| 5. {TIC {CCW 12 | | | {Transfer if unequal | 
fo -  fe----- }------------------------- }---------------- +-----+---}------ }-------------------- { 
q | 6. |Search Key Equal {Dummy Key {| C,S {OOO} 1 |Search for dummy | 
q | | | Address | | | | record. | 
qo.) bee }------------------------- fevnnn anna fa anan pnw fan nnn fen : 
q | 7. {TIC jccw 9 | | | [Transfer if unequal. | 
}------ $------------------------- $--------------— $-----4---}--—---}----------—-------- 
i { 8. jTiIc fccw 14 | I | {Transfer if equal. | 
1 [------ }------------------------- }----~----—----- {-----4---+--—~- }-------------------- { 
4 | 9. {Muitiple Track Search | TOBUPLIM + 3 { c¢C  |ooo| 5 |Stop search at | 
4 | | ID Equal | | | | J limit. | 
}------ }------------------------- $---------------- }~----}---4------}----------=--------- { 
q ,10. | TIc jccw 3 | | | | Transfer if unequal. | 
------ }----~------~------------- 4} --------------- =} ---- ff -- f= =f 
j11. | NOP | ; s | |} 2 {Search limit | 
| | | | | | | reached. | 
}------ }--~---------------------- ------~---—---- $-----}---}---——- }-------------------- { 
j12. |Search Key Equal |Dummy Key | C,S JOOO] 1 | | 
| | |Address | | | | | 
p----—- $-------------------------}------—--------- +----- t---}------ }-------------------- { 
J13. | TIC jccw 4 | | | {Transfer if unequal. | 
| | | | | | | 
t------ $----~----------—--------- }-----------—-~-- }---~-4-—-}--———- }~------------------- 
ji4. {Read Data | IOBDNRCF + 6 {| C,S |O000] 1 |Read dummy record's | 
| | | | | | Jposition (i.e., R). | 
}------ }-------------------—---- -t-- ~---}----- $~---}------}-------------------- 
}15.2 |Seek cylinder head | IOBDNRCF | C |JOOo| 6 |Seek back to track | 
| | (CCHH) | | | | jcontaining beginning | 
| | | | | | [of block. | 
+ 0 peooe-- }------------------------- }---------------- $----- $---}------ }-------------------- { 
}16. {Search ID Equal | IOBDNRCF + 2 {| c¢ jooo}| 5 |Search for dummy | 
| | | | | | | record. 
f------ $------------------------- fo—--=2----- === $----- +---+------ }-------------------- { 
e j1i7. {TIC jccw 15 | | | |Transfer if unequal. | 
| | I l | | | | 
}------ }~-~---------------------- $---------------- $----- +---}------ +-------------------- { 
j18. {Write Key-Data [Key Address? | Cc |000|Key |Update the Key | 
| | | | | | Length]| Portion. 
}------ $------------------------- $~--------------- +----- +~--4------}-------—------------ { 
{19. [Write Data |Area Address? | {000|Data |Update the Data | 
| | | | | | Length| portion. | 
}------ }---~--------------------- $---------------- $----- $---}------ $~------------------- { 
{20.1 3|Seek cylinder head | TIOBDNRCF | Cc |O00j; 6 [Seek back to track | 
| | (CCHH) | | | | |containing beginning | 
| | | | | | Jof block. | 
Saar near Dea ee Pee ae ea Be Be SS Mi rh hg ce J 
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r 1 
| Channel Program for Writing a New Block of Fixed-Length Records Using Extended Search | 
j (Type DA) (Continued) | 


rea a Vr a ee a es ee ee ee hs Tee Te ee ee 
}21. |Search ID Equal | LOBDNRCF + 2 |} ¢ |jooo} 5 | Locate the block | 
| | | | | | j just written. | 
p------ }~------------------------ }---------------- }-----}---}------}=------------------- 
{22. jTICc jccw 19 | j | |Transfer if unequal. | 
| | | | | 4 | : 

}------ }~------------------------ }---------------- ¢-----t---4------ }--------~----------- 
| 23. |Read Key-Data | | S,K [000] 256 |Read to validity | 
{ I | | | |check. 

}----~- 0 ay agin er eI 1 eee re eae Cece y eee ear re i a Sa cet en | 


|*This CCW is present only if track overflow has been specified. | 
|?This address is obtained from the DECB. | 
{2ccWs 20-23 are included only if the field DCBOPTCD specified the write-validity-check | 
| option. | 
L 
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